This is a draft.
Our team is currently cracking away at creating more content to make our Handbook something increggdible. Soon, you'll be able to explore it fully. In the meantime, think of it as a carton of eggs, each section packed with the potential to deliver something eggceptional.
The Back-end is the underlying tech layer that supports the data processing and storage. Usually hidden from everything, it is what handles most of the business logic in any application.
Our ultimate goal is to create beautiful experiences, but the quality of the Back-end is as important as any other area. A solid Back-end serves as an excellent for a quality Front-end application.
What makes a good API?
A great API is a service that has enough documentation to be understood, is not necessarily complex and is predictable because you don't need to read an entire encyclopedia to use it. A great Back-end is a good API, maintainable and simple, meaning that changes should be possible without too many constraints.
The frontier between Front-end and Back-end
Where do we design the separation between the Back-end and Front-end? Hard to answer… We do it based on tech stack, purpose, and many other project-specific aspects. The Front-end's Back-end serves more than anything related to the state of the Front-end or cosmetic behaviour. Sometimes our front-ends do have server code, but we call this a back-end-for-front-end, and we consider this part of the Front-end scope.
We are flexible, but we often have entirely separate applications with their own code, deployment and team. This allows us to have independent responsibilities, split the workload (while creating some in the process), and keep the quality to a maximum.
We are not technology chasers. We try to keep complexity to a minimum. It's much more gratifying to build something that works well, is agile, and needs as little maintenance as possible vs complex systems that require all your energy.
We also really like back-endless software – if we can avoid having more pieces in a project, why not ditch them completely? This obviously depends on the project, we are always eager to test new tools, especially if they help us reduce the complexity of building and managing the software.
We are always experimenting with different tech, to see how can it helps us ship the our products. We just don't settle with something because we are used to it, and give ourselves lots of freedom to explore and learn different things.
Our primary choices for technology are:
Elixir and the Phoenix web framework. Elixir does have dense syntax, but it not only works really well, as all the tools built around it are one of the best in the market.
Postgres (RDBMS). We love Postgres, it handles everything we throw at it. It performs surprisingly well and, most of the time prevents us from having to use specialised databases.
GraphQL For communication, we really like GraphQl, not only because of its endless possibilities but also because of the great tooling and integrations built around it.