Being ahead of the curve, and what that means?
30th of August 2022, by Oliver Dixon
Time & Money
We were in a meeting last month where the founders tech lead had created a system using .net technology from 2012, in 2022. We had to stop the meeting and say that it won't be possible for any of our teams to work on their existing platform.
Why?
It's hard to find developers who want to work with old technology.
I want to help businesses understand what it means to use good technology and why being ahead of the curve is important. This will help them make informed decisions about their next projects.
Finding the bleeding edge
How? YouTube & Twitter. We follow great bleeding edge tech & founder channels like Fireship.io, Ben Awak, John Coogan and many more.
Testing the bleeding edge.
We create a mini-application with a login, simple home menu, and content. During this process we try to make the application as close to release it could be, to test what the framework/library limitations are.
Learning from history
Polydelic has used many different tech stacks to release our applications.
Some of our tech transitions over the years
Mobile
Native → React Native → Flutter
Backend
Firebase → Express → GraphQL → tRPC
Web
Angular → React → Svelte/Flutter
Hidden Teams
Why does it matter?
We've talked about the benefits of using Flutter in our post “Container apps are the future” so let's use our back-end technologies as an example.
Our first “backend“ was Firebase Admin, which is a wrapper on Google Cloud and allowed users to make queries directly to the database using security rules.
Initially it was great, until it wasn't.
Our first app for Polydelic
Our first app hit over 1 billion transactions a month. It was in the top 10 trending app for the App Store & Google Play; in the USA for a few weeks after release.
Firestore had the promise scaling for you, we found out that this wasn't true. Queries started to take over 30 seconds; resulting in a poor user experience. There were very silly limitations like not being able to use a double where clause, which made some queries impossible; Geo-localization for example.
And the list goes on.
In the end the product suffered for a week before we took the decision to migrate it from Firebase (Firestore Database) to a MongoDB hosted by Atlas. This solved many of our problems but cost the client; the app had negative reviews, and lost business not good!
Short-term wins, long-term losses
We learned here that relying on fully-managed services can be risky. You put your trust into another hidden team, another team to fix bugs, another team to add features, another team to maintain servers, another team that has no equity stake or teeth in the game.
Discovering great technology
For years we started using RestAPIs which is the most popular way to make APIs today. But we were never happy with it.
There were some issues when using Rest, for example
- Having to write docs, JSDocs being the simplest way. But updating these and maintaining them gave developers a headache.
- If you want to use automatic documentation libraries, they were messy and verbose, not fun, Swagger for example was really verbose and boring.
- Having to copy/paste models from client to server and make sure both are updated or versioned properly, risky.
- Lots of annoying manual tasks, like input validation or output validation.
RestAPI - Meh
GraphQL?
We transitioned to GraphQL; it was a bit better, we got the API documentation automatically which was a big cost saving.
Using ApolloQL we could also get a nice developer play-ground that allowed the quick creation of queries and models. GraphQL had some flaws though.
- Verbose, queries were rather large.
- Lack of basic features like “select *” primitives. We publicly requested the GraphQL team to consider adding this, never got any response.
- We had to use decorators (thanks typegraphql) otherwise writing basic endpoints would have been multiple files and classes and would have been a waste of time to maintain or create and simply boring for the developers to interact with.
- Updating routes was causing bugs with properties missing for clients or not updating X-Y-C query string, became a major headache.
- Modifications were tricky.
- Developers were nesting functions, making it tricky to navigate the docs.
GraphQL - Meh
Welcome tRPC
Finally we found the ultimate way to interface with a backend. This is a small almost unknown library that will most likely replace current API technology in the next few years.
Simple is best, less code the better.
No bulls**t. Just code and get on with it.
- Automatic models, no duplication, errors, etc. Not only did we not need to write models on the client anymore, but it was type-safe: automatically. Big cost saving in time saved to write backend APIs.
- Automatic documentation: client, backend and via the web. Using the playground utility we had web documentation automatically, no need to write anything out manually, everything was inferred directly from the code.
- Optional Rest backup API. For any frameworks that couldn't support tRPC type inference there was an optional, very straightforwards rest API plugin that works great!
- Our developers were writing significantly less code that was safer and well documented.
A developers dream! Just write code and get s**t done!
tRPC - A gem for our developers and partners
Being ahead of the curve and trying/testing new technology helps us save time and money for our partners in the long term.
Looking at new projects in tRPC vs. GraphQL, vs. Rest; we can see that tRPC projects are taking a 3rd of the time to develop the same endpoints and have less problems with QA and bug bounce backs.
These projects going into the future will be much easier to maintain and will cost significantly less to develop on; also attracting better talent.
If you have any technology tips we should try, please send us a message below!
