How it works?
A short guide explaining the whole code.store in a single page. Don't say thanks! 👊
Last updated
A short guide explaining the whole code.store in a single page. Don't say thanks! 👊
Last updated
The service you are building is going to be consumed by your clients (real clients or frontend teammates) via an API (GraphQL), which your service is exposing. That is why we believe in the schema-first approach, where you are required to define an API (or a schema) first and then develop a backend that provides data for this schema (as opposed to a code-first approach where the schema is generated from the code you write). GraphQL schema (or API) IS YOUR PRODUCT! That is why everything starts with a schema at code.store.
We strive to simplify your life, and so we are taking the complexity of database management from your shoulders and are generating database tables automatically from your schema. Whenever you add a new type, field, or modify the existing ones, our platform generates migrations and TypeORM Entities (also called models), which you can use to write business logic in resolvers.
At the moment, we are supporting Typescript/JS services, thus the generation of TypeORM models. We are going to support other programming languages as well, with PHP being the next one.
When ready, push your changes to our cloud using the CLI to our platform. code.store will check your code, containerize it, and deploy it to a private environment. You can then promote your service to the Demo environment, which is used to let every developer in your organization experiment with your service and check if it corresponds to the needs of their project.
Once created, your service cannot be used per se in a production application or site, you need to add it to a project. Projects represent applications or sites where your service is used. Each service can be used in as many projects as you wish. You can use our web UI or CLI to add your service to any of your projects. Every developer in your organization can create projects and add services to them. A service-instance is created when you add a service to a project. It's an entirely isolated version of your service: it has its dedicated environments, database, and logs.
For each service-instance in a project, you can define a rate-plan so that you can bill your clients monthly per service usage (price per call) or as a subscription. The core idea is to bundle together costs of building the service, its maintenance, support, and hosting in a single simple fee that your client pays. Up to today, you can sell and bill services to your clients only, but we'll be launching a public marketplace as soon as we have enough on-board service makers.
