Is FaunaDB A 'Legacy Back-end' Killer?
The rise of FaunaDB is all but assured with the release of version 2.7. Spurred on by a unique and complimentary feature set unlike any other.
The aim is to help anyone build complex apps from basic GraphQL schemas and a little elbow grease.
Data interactions are as delightful as any GraphQL API. A geo-distributed relational noSQL database under the hood provides a peace of mind.
Most impressive of all is how your front-end users can now login to your "app" via the standard Fauna client.
This direct-to-database login ability makes perfect sense when you think about it. The most efficient way to authenticate is to verify identity right where the secret hash lives! In a few commands role-based access control restricts users to their own data, or however you like.
Combine these two powerful features and you get one bold assertion... Developers can completely do away with the need to build a legacy back-end.
That's right, Fauna has made the back-end server optional.
Back-ends in any language are hard to scale. Back-ends are nontrivial to stand up and host. And what for? Usually we arrive at not much more than a wrapper for authorized CRUD actions. A better architecture for our apps would be welcome.
An often overlooked aspect is the lack of tools required for a Fauna centric app.
Many frameworks get lauded for having a great tooling ecosystem. Which is both true and welcome in the case of GraphQL. But does all that praise for the external tools reveal the shortcomings of a system that was too small in scope?
FaunaDB is larger in scope than any other database you may have encountered. The cloud IDE itself aims to need no extra tools or dev environments.
The company believes in a direct to database, truly serverless future. For now, it's all hands on deck minimizing the new set of trade-offs that come with the uncharted territory.
Some Gotchas
There is an incredibly steep learning curve for the Fauna Query Language not at all aided by the documentation which dances around this fact with a low word count. Prisma is magnitudes easier to reason about once you accept the bloated hosting arrangement (prisma2 might also be poised to take advantage of the best that fauna has to offer soon).
Don't be fooled by the easy start GraphQL association either, behind the curtain the FQL paradigm is as mindbogglingly intricate as it is powerful, and FQL is required learning for any meaningful data interactions.
FQL means vendor lock-in is assured but self-hosting is possible.
There is no rate limiting for end-user invocations or a way to set them globally without going back to a DB proxy backend architecture. The bill-shock anxiety would be off the charts if not for the ultra low costs and possibility of fine grained user role 'middleware', which gets cumbersome.
Some arbitrary rate limits apply to the GraphQL endpoint which can make successive calls slow (>5 seconds) and difficult to diagnose.
There is no way to understand which indexes or function calls are the heavy hitters that may need further tuning. Fauna's philosophy of 'forget about database tuning forever' may need a little tuning.
FQL can feel claustrophobic e.g. there is no way to grab the current array's index value inside an array iteration — frustrating when the vast amount of your sandboxed lambda functions are geared towards iterating over an array or map.
There are no cache tweaks that you, as a cloud user, can benefit from with regards to cost-saving, again without going back to legacy server backend architecture. The returned HTTP header may well indicate an AWS cachehit for your FindUserByID call but it appears every invocation is being billed as if it were a full execution each time.
The Best Bits
Extremely fast improvements like the new roles features and GraphQL mentioned. Cloud users are automatically updated to the latest version.
The cloud IDE is minimal and functional, much more pleasant than any CLI. With no external tooling required.
The amazingly simple built-in multi-tenancy means, like never before, you will be reusing a lot of effort in your data manipulations all the time, easily. Every database can have whole new databases ad infinitum.
Conclusion
Fauna DB is production ready for anything you are prepared to throw at it, from CRUD to eCommerce. It has been for a long time. Future proofing itself by ushering in that far away future where FaaS and DBaaS collide. Unfortunately this tech is not yet a no-brainer for your next prototype app.
Consider using it for your next medium sized app, something with its longevity assured to make the extra effort of learning a new paradigm worth it — that is, provided you don't need caching or rate limiting or long-lived connections in your app. Any reasonably sized app will stretch across the breadth of Fauna's functionality.
Definitely consider Fauna if you need multi-tenancy.
A new product must be 10X better than the existing product to succeed
Everyone is ready for a project without CORS issues and ENV vars but it must be said that it is not all that hard to stand up a server. The savings here are not in developer time for one app. As with current serverless platforms, it's all to do with long-term costings multiplied by the number of apps factoring in scale. And this paradigm allows for a great deal of any sized apps to be hosted globally at a very reasonable pay what you use rate.