Ask HN: Do you need more than front end and Firebase education to ship product?

If you are trying to make money and ship a product, then I have seen far worse than just a Front end and a Firebase. Go for it. Get your product in front of paying people as quickly as possible, then sell sell sell. You'll probably fail (the default state of a start up is failure), but you'll learn a lot along the way.

If your hope is to learn how to write code for other peoples products and have them pay you, it would benefit you to get a more full stack education. Node would be good. Rails is nice. Django is nice. .Net works well. Java is good.

It just depends on what your goals really are.

If you have good ideas for products, don't waste time thinking about their scalability at first. Just use whatever tools are easiest for you to learn to get the job done, get it in front of people, and learn what you need to from there.

Your plan sounds good to me. There are quite a few all-in-one ish solutions that can help you with this, usually with pretty modern technology, like Gatsby. https://www.gatsbyjs.org/ Do a bit of research, learn what you think you need to get shipping, and ship.

If you can accomplish what you want to build with frontend + firebase, then you've accomplished it! You can always fill out the backend skills later on. Firebase in particular is designed for rapid prototyping, "hackathon" style projects.

With that said, building a toy API with authenticated data (user registration and the like) will help you understand the various ins and outs and will give you a better understanding of what services like Firebase offer and what their value is.

Don't focus on premature optimization - by doing things in a naive way at first, you'll understand why various engineering practices became commonplace and you'll be able to more judiciously apply them instead of cargo culting.

There's tons of ways to skin that cat, best thing to do is pick one and go for it.

Do you have any coding experience? The Odin Project is great but when I first started from absolute zero[1] it was a bit too much too soon. I switched to Colt Steele’s Web Dev Bootcamp for ~$15 on Udemy which gave me a really solid beginning and then went back and did The Odin Project curriculum.

Everyone is different of course but trying to install Git and use the command line before I even started the first lesson should have been my first clue that I needed just a little more of a foundation.

[1] As in my entire “programming” knowledge was the CSS I had used to customize MySpace a decade earlier.

The hardest part about entrepreneurship is making a product/solution people actually want. Keep in mind, most things you build, no one will want. Most entrepreneurs have a GitHub account filled to brim with dozens of projects that no-one or few ever really wanted. When you do build something people want: that's gold, that's rare.

The technicals can always be learned later, or you can pay someone to do it. These days, there's a LOT of apps that can build apps/websites for you.

On the other hand, if you want to become an engineer, then by all means, learn the technical stuff and ignore the rest. try to make a conscious choice: 1) i want to build a business or 2) I want to learn engineering.

Not affiliated but I've been enthusiastically watching the development and launch of userbase.com which might be just the layer of abstraction you're looking for

Are you doing it to actually build a business or sharpen your skills? If former, start with Firebase and pivot when you have a proven market. If latter, starting with both backend and frontend is a no brainer.

But I'll never underplay the importance of having both backend and frontend skills -

- It's a core set of skills which will pay off multiple times in the future. - Easier to pay off the tech debt in the long run. People seriously underestimate the capabilites of postgresql + ruby on rails/express + a frontend like react. - It's much better to be dealing with the problems of an open source software than a proprietary one. - Learning how everything works together - how to frontend is wired to the backend and how the backend models the data in the database and how to deploy all of it together - is invaluable. - Almost always cheaper than proprietary solutions.

Learning between the two is a matter of tradeoffs. If time is of essence, then you probably should choose things which are easier to learn and manage. However, in the long run, proprietary solutions rarely beat the combination of postgresql + rails/node + react.

I'm not sure what exactly is meant by BAAS (I get backend as a service... but that seems quite vague to me). I don't have experience with firebase, but I have used serverless on AWS API Gateway / Lambda with AWS Cognito for auth and dynamodb as a backend database. While the raw hosting cost is more expensive I assume than if I were to roll my own docker/kubernetes/elasticbeanstalk/etc solution, it scales without me worrying about it and the the extra time it gives me can be invested elsewhere. I believe that extra time has given me--as an indiehacker--a significant advantage over other, larger, competitors.

My experience with managing servers, doing deployments by hand, setting up automated deployments has been 100% not enjoyable. So I prefer to pay AWS to handle as much of that as possible for me.

Absolutely go for it. Firebase scales up well so you won’t need to redo a lot of things when your product starts getting more users. I would suggest to have a look at Nextjs or Gatby for your frontend if you are know React. But to your question, Firebase has all the tools for even large scale app.

Skip firebase and use Hasura (GraphQL on top of the rock-solid PostgreSQL database). That way you'll have a solid relational data-structure from day one but with the ease of a BaaS.

FWIW, I just delivered a product (front-end in React+Typescript) using just that. I started writing a back-end in AzureFn+CosmosDb+some other stuff) and switched over to using Firebase for auth and the DB. The cool part is that because of the nature of the Firebase client APIs that emit change-notifications whether it be from local or remote changes, GFB acted as my state/store so I was able to get by w/o any React state mgmt frameworks (like Flux or Mobx, etc.) - though I also did so for expediency as I'm normally not a front-end dev so I wanted to ramp up on as little as possible. Though I'm still an Azure/.Net fan for back-end work, I appreciate that GFB provided only what I needed (at least for this app) but no more.

I was mentoring a friend who was learning frontend and he really just wasn't enjoying it the way I did when I went through that process. We started looking at the backend and it turned out his inclination was really more towards DevOps and that's what he got excited about. It's hard to learn something in your own time if you're not feeling excited or motivated about it.

For myself, I started with HTML and CSS, and had a lot of fun with that. Then when I decided it was time to learn JS, I hit a brick wall. I almost quit then and there thinking programming was not for me. But I was also determined to do something different with my life than I was currently doing. So I switched gears and jumped into Ruby on Rails. Ruby really clicked with me in a way that JS did not, perhaps because it was somewhat more readable and less syntax getting in my way. I got into it enough that I signed up for an online bootcamp. That's a whole different story but the short of it is I learned Ruby on Rails and that enabled me to get a job at some point soonish thereafter.

And you know what? In the end I came back to Javascript and I actually enjoy working in the frontend (with typescript mostly now) more than the backend side of things. I think maybe Ruby taught me how to rewire my brain for programming and then Javascript felt a lot more friendlier than it had previously. It's a lot of the same paradigms, just re-wrapped in different syntax.

I guess, my point is, try to start somewhere, but don't be afraid of exploring. There's no right answer for all of us.

Html/CSS/JS is a good starting point. Firebase or AWS Amplify is a good augment to that although I'd try just purely static sites with maybe some serverless functions sprinkled in if needed. Netlify Functions are an easier entrypoint into that, and I believe they are just AWS Lambda's underneath: https://www.netlify.com/products/functions/

Try to find your niche and focus down on what gets you excited. I dove into some obscure frameworks and languages at times that might have seemed ill-advised to focus on during that stage in my career. Some of these paid off by becoming popular but even when they didn't, I learned a ton.

To build a prototype: no. You'll build something that someone can use, and then you'll find the parts of it that aren't working and fix them. You'll learn what you don't know on the way.

Don't think of each idea as "Product with N engineers and X DAU", just build a thing and then add incremental improvements.

This is like asking if one needs more than eggs and a pan to make a meal? Not if the meal is an omelette.

Can this be phrased differently by asking the other questions:

- What value can I deliver with what I already know?

- What things should I learn to overcome the difficulties encountered trying to deliver value (through a product) with what I thought was sufficient but clearly is not?

In other words, one wants to deliver value and start building a product as a vehicle of delivery with the skills they possess. At some point, the skills are insufficient to complete the vehicle to deliver value, and they either change the vehicle or acquire the skill.

My recommendation for anyone who isn't already too deep/stuck in their current stack would be to look at starting something with a PostgreSQL + Elixir/Phoenix/LiveView combo. You'll end up with an incredible foundation that would be hard to outgrow. Lots of the simplicity/structure familiar to Rails, interactivity like React, but without most of the downsides. Performance/scale/dx is about as good as it gets. I can't do it justice in a short comment but there is plenty out there to read up on.

The stack you choose is just a tool. Just like a builder using a hammer.

It's not so much how you build it is the real world problems you solve. Yes there are considerations as to the quality of you product and the costs associated with low quality code. But if you solve problems well for people you will have the revenue to clean that up.

Learn to code well, don't sorry that you don't have enough tools in your tool box right now. You probably don't need them. Just focus on solving problems for people.

I'd suggest reading the pragmatic programmer before looking into a new backend stack.

React. NextJS. Firebase. - add reading the docs for Firebase functions and you'll be able to ship pretty much any SaaS product you think of with pretty good architecture baked in with the defaults.

Almost by definition, that is what Firebase does: it allows front end developers to ship product. That is Firebase's purpose, and it is fit for purpose.

So: you do not need more than front end and a Firebase education to ship product, because Firebase was created to enable front end devs to do this.

Snap runs on Google App Engine so one can go pretty far using such services!

> [...] for a mix of fun, profit and self development.

Assuming you actually enjoy programming, fun and self development will likely come rather naturally as you build and break, find problems and develop solutions. If you have people looking at your products, even if they're just friends, learning to listen to their problems and solve them will also take you far.

Profit, on the other hand, is more difficult because that has far less to do with technology than it does with marketing and business. You could know every language, paradigm, framework, API, methodology, whatever and you'll not make a dime unless people see value in what you're building. Thus, if you actually have a real profit motive consider spreading your time between learning web development and business development.

> [...] how valuable would a back-end education be (node/express or ruby on rails), even if I end up going the baas route?

Even if you go the BaaS route you'll likely need some degree of backend knowledge to either a) have the BaaS do the right thing in the first place or b) actually understand the limitations of your BaaS, why those may be, and effectively evaluate alternatives.

In most cases, a BaaS will provide you easier ways of doing things like creating your own APIs or performing database operations. But at some level - even if basic - you need to understand your own APIs and how you're storing/retrieving data. You don't need to go particularly deep on any given topic (plenty of time for that) but you should be comfortable being able to explain your front- and back-end architecture to a fellow web developer.

> My product ideas are run of the mill Reddit for dogs, news aggregator, to-do list app type stuff

These are great starter projects; don't get discouraged because they are "run of the mill" because - as a developer - the value of novelty lags behind the value of productivity. A mediocre implementation of a mediocre concept showcases more progress as a developer than an amazing concept that doesn't exist.

SPAs are a lot of work to get right, if you want to stay within JS, node/express/postgres and Pug/html/css(with some sprinkled JS) would be faster and simpler IMO. You can still use Firebase's auth feature from the server.

I've been using Firebase in production since 2016 and I would not recommend it.

Once you learn how it works, Firebase will get you from 0 to 10 really fast but will slow you down as you struggle to go from 10 to 100. By then your app/product will have so much Firebase specific code that you will need to rewrite a significant portion of code to move out of it. Let me know if you want me to expand with specifics on why Firebase is bad.

If you need something easy to start fast I'd say go with Hasura. It will give you one-click GraphQL API over Postgres. Your front end will simply use standard GraphQL so you can change your backend without touching the front end. And Postgres is still Postgres. Even if you decide to completely rewrite your product you could keep using the same database.

Use firebase auth as the authentication layer. Then once a user is authed in just use mongodb as per usual in node or Postgres in rails, django etc

You pass the token to the DB via HTTPS decrypt and off you go.

Not if you don't mind depending on Firebase.

Pretty sure you can do a to-do list in Firebase, maybe even Reddit for dogs.