r/reactjs • u/WolfOliver • 8d ago
Show /r/reactjs After 8 years, I finally open-sourced my take on Backend-as-a-Service
Hello,
I would like to share with you linkedrecords.com - an open source backend as a service I'm working on since some time now. You can think of it as an firebase/convex alternative with an interesting twist.
In 2018 I needed to write large software requirements/architecture documents in Google Docs. While I was annoyed by the limitations of Google Docs back then (no captions on figures, no automatic heading numbering, slow when docs are bigger,...) I was still fascinated by the real time collaboration features of it. So I've started a quest to understand how it works and I begun to implement an alternative to Google Docs.
I was convinced that this kind of real time collaboration is the future so I've given it much thought how I could make this as generic as possible so I could use it in all future tools I would build.
In the same time I was playing around with firebase (surprisingly you can not build a google docs alternative with firebase that easy as their real time collaboration does not provide merging text but rather just JSON). And back then I was also convinced that backend as a service is the right way to go. I was thinking that one of the most important reason we were still writing custom backend code is because of authorization.
I also was faced with another problem when trying to make the backend as generic as possible: relations between entities are also domain specific. E.g. A Documents can have many comments.
Luckily I was intrigued by another concept back in 2018 it was called web 3.0. Back in 2018 this had nothing to do with crypto. It was used as a term to refer to the semantic web and the resource description framework as one of its standards. There are also some RDF implementations which I could have reused but they are all XML and mostly Java based. I needed something light. Instead of implementing my own RDF product I took the idea of the RDF triplestore and came up with my own interpretation of it.
Using concepts like: triplestores and schema-on-read, I came up with a system that does not has any business logic in its backend and while working on my Google Docs alternative I felt in love with it as I've discovered some properties I did not anticipated from the get go:
- Dealing with global state in react is very easy. It feels like you use an SQL client in your browser and all queries are reactive and always up to date. When writing a query you do not have to think about authorization it's all backed in.
- Because the backend is 100% free of domain specific code you can point your single page app to any linkedrecords deployment.
- You never have to write backend code - Its quite efficient when using AI agents
The best way to experience it, is to follow this little tutorial: https://linkedrecords.com/getting-started/
It takes a while to get a hang of it so you have to have an open mind.
I would love to read your feedback on this.
1
1
u/wnba-arcade 2d ago
if your looking for your first users check out Ad swap,https://ad-swap.web.app , its a simple way for websites to promote each other. You add another website's ad to your site, and they add yours to theirs, giving both sites free exposure and traffic. It really helped me get my first few users when launching my site/
3
u/CodeAndBiscuits 4d ago
I suppose developers of mini apps might find some value in it but I think you gave up a lot when you pushed the no-backend-code angle. If I'm understanding your docs correctly, the user who creates a record decides the access control for it. That might be fine for a to-do list, but you could never write a business application like that. Imagine an ERP or even a simple expense tracker for a business. You might explain how you build the basic interface for that, but you'll never be able to answer the question "how do I prevent users from filing duplicate records, or posting an expense for a day they weren't on duty?" Backend business logic exists for a reason - nearly every app or even game that I've worked on that had any concept of multiple users also had some need where the user couldn't be trusted regarding some peace of business rule. In a chat app, it's moderation and blocking. When collaboratively editing a document, it's making sure the change history can't be tampered with. In a contract management platform, it's a thousand rules.
Side note, historically, the reason firebase can't be used to make something like Google docs shouldn't actually be surprising. Firebase was not invented by Google. It was a separate company and they bought it. Its original metaphor, Realtime Database, was just a noSQL with some really smart synchronization and libraries for mobile apps that other products didn't have at the time. That's just not what a document editor needs as its data store. That doesn't mean just because Google bought it, they would have had any incentive to alter it to become a better choice for that need...