Initial technology stack for building a SAAS
Hello indie hackers 👋, today I would like to explain which is the initial tech stack that we have selected to build www.teami.io.
We are using:
- Reactjs
- Redux
- Draft.js
- Firebase
- Semantic UI
- Styled components
💻 Why are we using React + Firebase?
The main reason to use React over Angular and Vue is that the founders already knew React and it will be faster to develop it, also React has a huge community where you can ask for help or advice.
With React also we can keep more understandable for future developers (React is a bit stricter, more readable and in the end, it's just plain Js and JSX) and when we need to find new developers to join the team it won't be a problem if we use React.
👨💻Why Firebase? Mainly because of speed, We can have a backend really fast and start to try the product with users. Firebase handles things like your database, authentication, and hosting and also it has a generous free tier.
With Firebase you can build awesome products and faster than building your own backend. In the future if the company needs it and you can't scale the product it might be worth moving on from Firebase, but at the beginning building the right product is the most important for us, and with firebase, we can do it faster.
What are your opinions on using Firebase to build a SaaS?
I think Firebase is a great choice for an early-stage SaaS. It helps you launch faster with built-in authentication, database, hosting, and real-time features, so you can focus on validating the product instead of spending months building infrastructure. The main thing to watch is long-term scalability and vendor lock-in, but for an MVP and initial growth, the speed and developer productivity benefits usually outweigh those concerns.
I've used Firebase on a couple of small projects years ago, and there is a reason that I never looked at it for any project of significant size. Querying is slow and complicated, and you end up duplicating data all over the place just to get 'relationships' working the way you want to.
I admit it was back in the early (pre Google) days, and they may have improved things some, but in the end, I don't think that any NoSQL database can handle multiple table complexity (my current project has 200+ data tables, and there is NO way I could run that in a NoSQL system, though there are parts of it that do run on RethinkDB, but only about 5 data tables).
But at the end of the day, it is all horses for courses, and you may find that Firebase suits your particular app really well?!?
Hindsight is 20/20. Firebase has cost us more time/effort/money overall than it has saved us. When you're scaling on Firebase, every single moment you wish for having gone with Mongo or any other regular DB.
Every single Firebase billing alert/surprise, node listener, query limitations, has really killed us. It has made us compromise on the way we design our DB Objects, and so much more.
Sure @Devan at the end each project is different, although with the new cloud firestore database it has improved a lot.
I was looking at Firebase, and while they do have a pretty generous free tier, reads can add up pretty fast (depending on your app of course). Then you might start thinking about structuring your data in a way that results in less database access, doing some parsing/filtering in the frontend. As a principle I don't like to have to be concerned about that.
If using Firebase I also think it's wise to isolate all DB access in an API context in the frontend, so that this is nicely isolated and not tangled into the whole codebase. Makes it easier to change to something else than Firebase later.
I would also be concerned a about how easy it would be to migrate data from Firebase to e.g. PostgreSQL. I've never tried that and I've no idea if that would be easy or hard.
I don't have looked really well yet at how to do the migration of it, I know it can be a concern in the future, but I wanted to test my hypothesis first with the product and see the potential interest and use of the users.
Firebase has a custom implementation built for Polymer (Both technologies from Google) that includes templates for multiples starter-kit. The stack polymer/lit-element + firebase database + firebase hosting is extremely powerful with hundreds of advantages.
https://polymer-library.polymer-project.org/
As a backend developer, I find it very interesting how a lot of startups now days are going "backend-less". I have used Firebase a bit, but struggle to see how it can completely replace a backend?
Very interesting concept! This is exactly why I'm currently learning React. I don't think C# is going away any time soon, but do want to prepare myself to have the right skills as it seems more and more trendy to completely ditch the backend.
I've used Firestore for both my mobile apps and now using it for my Slack app I'm about to release. I absolutely love it as it lets me move fast without building out a back-end. My data structure is pretty simple and I don't mind duplicating data (just took me a while to get used to initially as I never used NoSql-like stores before).
I've been messing with Firebase on and off since 2014 and I've never seen it actually end up as a faster development experience than a good back-end framework like Laravel, Rails or Phoenix + some reasonable auth libraries.
In the past, what it really offered was reactivity, which was considerably more work with most frameworks (other than Meteor). Now, that kind of dev has become much easier and Firebase has expanded into more traditional database use cases + some various auth tools.
The downside is high and unpredictable costs as you scale, often times performance issues, vendor lock-in and more headaches integrating with external tools. I don't think this will speed up your development over the course of a month or year and I do think it will make it harder to build a good product unless nobody on your team has much experience as a back-end dev.
That can be true, I have to say that I am not a really good backend developer and my main knowledge is on the frontend, that's also one of the reasons to use firebase for me.
A tried and tested stack.
Why do you use Redux. I am honestly asking. I usually don't get why people use Redux.
I wondered the same. Redux leads to all kinds of boiler plate that's a poor trade-off for those wanting to move quickly. Literally half my friends running startups have told me the regret having used Redux, and most the other half is on Vue, Stimulous/UJS, or something minimal!
Early on, the goal is launching and iterating. Cheaper, better, faster, pick 2. Early on, it's cheap and fast. Better code can (generally) wait.
For me, the big sell is that Redux enforces constraints that keep my code structure clean.
I need to reason about where something should live in the state tree, and create clear interfaces for how to modify it in the state tree.
Coming from a project or two with super nasty (self inflicted) state management, I like that it forces me into tidying it up.
I spend a bit more time working out where something should go in app state, and 100x less time chasing issues about application state.
I use Keajs with it and barely even notice it. Enjoy it much more than using state.
I haven't caught up fully with all the hooks etc, so may be i'm an old man in that regard.
This comment was deleted 6 years ago
This comment was deleted 6 years ago
I don't have looked really well yet at how to do the migration of it, I know it can be a concern in the future. I could not answer to which is the best solution to do it.