Product Documentation
Search and work with Neurosell product documentation. Here we have given you a list of all the materials / documentation sections you need to work with
Last updated
Search and work with Neurosell product documentation. Here we have given you a list of all the materials / documentation sections you need to work with
Last updated
Let's take a look at what products and services we provide for the community and our customers:
NeuroCart
Ecommerce engine and plafrom
Parallelix JS
Unified JS client for web applications
Maviton
Coming soon
Coming soon
AI powered virtual try-on. Currently in closed-beta
We do not maintain public documentation for certain internal developments and technologies. You may also notice that some products are closed source and do not have their own public Git repository.
Now it's time to talk about the most important thing - the network architecture of Neurosell projects. Here we have described the architecture on which most of the applications and websites we develop are based.
The main features we try to adhere to are automation, operational stability, speed to scale, and minimizing environmental impact. We also actively utilize CI/CD for improved product cycle performance
Let's take a look at what steps are being taken to launch products in the Neurosell ecosystem:
The client instance of the application is launched (let's say it will be a store based on NeuroCart). To do this, a command is sent to the build server, which forms a fork of the main repository, changes the configuration of extensions and sends the product for building, after which the built product is sent back to the repository and will be ready for deployment.
Next, the deployment is performed to the application cluster, which contains: application server, database cluster and S3 storage. Project information is added to the Neurosell monitor
The finished product connected with Parallelix and other services is placed on all available platforms at once.
The developer works with the client repository if they need to make any changes.
Thus, we isolate all our projects and those of our clients, delimit rights, and reduce the load on servers through flexible horizontal scaling in the cloud.
This describes repositories that are not directly developed but are maintained by the Neurosell team or members of the Neurosell team.
GameShield for Unity
Unity UI Framework
Unity Crypto Library
Unity XScaling Framework
Three JS Upscaler
Let's take a look at the technology stack that the Neurosell team works with when implementing products:
NodeJS - In general, in my bearded years I wrote back on puffy, but we live in the 21st century and I wanted to take something faster and more flexible, understandable for further development state and universal. Yes, of course there are still different Java, Python and Go, but here the question of experience, feasibility of some solutions and the possibility of hiring a team quickly arises. Of course, we use Python (for AI services) and C# (more on that below), but the main products work on Node.
Express - Staying on the node. Why Express? After all, there are more modern solutions. However, my hands, beaten off in gamedev, say that the simpler and smaller the framework, the better. I didn't want to drag dozens of libraries, some of which won't be used in 99% of cases. Simple rationality. And Express is known by all noders.
C# - For some heavy calculations, we use C#. I think the advantages of compiled languages over interpreted languages don't need much explanation, besides, we use Shared code (partially overflowed from gamedev projects), which can still be deployed in WebAssembly, where JS just can't achieve the results you need in the browser.
JavaScript - Yes, I'm a stickler for pure JS, however I have to use it minimally. Mainly because there are people in the team who are used to working with typed languages and don't know all the pitfalls of JS.
TypeScript - It is used for basic development of critical components. So that there are no errors with types. It may be unnecessary, but it often saves life.
Tailwind - Why Tailwind and not Bootstrap? We actually use Bootstrap too, just not on all projects. Tailwind is more convenient. Bootstrap allows you to develop simple applications faster. That's all for now.
Sass - For the most part, have given up on pure CSS. It is more convenient to use selectors and work with variables. And in any case we will get CSS at the output.
Webpack - Why him? It's as old as the world. Well, in fact, even though it is ancient, it is well studied, and it copes with its tasks very well. When properly configured, it does not cause any problems. Hot Reload also helps.
React - This is where I am impressed with the similarities in our UI frameworks in the gaming industry. React bindings and all that. Yeah and it's just already an industry standard.
PostgreSQL + Sequelize ORM - We mostly use PostreSQL, for we have our hands full. But in general, nowadays there is ORM and we use Sequelize. Less headache when designing queries, convenient work with schemas and models.
GraphQL - For internal work of services - GraphQL is used because of its convenience, but as external handles of work with API - Rest is used, because it is more common and understandable to other developers.
Rest API - For external requests we use the more familiar Rest API.
Information about the core stack is provided here, with no indication of the additional technologies on which, for example, the virtualized AI stack is built. We describe such technologies in specific cases
|
|
Examples in
Docs and Examples in
Docs and Examples in
Docs and Examples in
