
Ask HN: Do you need more than front end and Firebase education to ship product? - Goldar
Whilst my world is on hiatus for the foreseeable, I&#x27;ve decided to learn enough web development to ship a few product ideas I&#x27;ve had on the back burner, for a mix of fun, profit and self development.<p>Plan A was to just learn front-end development (HTML, CSS, JS, framework, UI&#x2F;UX) and use a baas like Firebase or AWS for the back-end.<p>Now, I&#x27;m a little concerned that relying on front-end and baas will bottleneck me in some way that isn&#x27;t obvious to me as a newbie.<p>Given the above, how valuable would a back-end education be (node&#x2F;express or ruby on rails), even if I end up going the baas route?<p>Notes:
My product ideas are run of the mill Reddit for dogs, news aggregator, to-do list app type stuff.<p>I&#x27;ll be following one of the Odin Project&#x27;s curriculums.  They offer both front-end and full stack learning tracks.<p>-Front end  https:&#x2F;&#x2F;www.theodinproject.com&#x2F;tracks&#x2F;3<p>-Full stack Javascript  https:&#x2F;&#x2F;www.theodinproject.com&#x2F;tracks&#x2F;2<p>-Full stack Ruby on Rails https:&#x2F;&#x2F;www.theodinproject.com&#x2F;tracks&#x2F;1
======
trcollinson
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.

~~~
tomComb
Agree, except for that last part.

At this stage OP won't know which backend language/tech will be best suited to
whichever idea ends up taking off.

So, best to just use whichever is most popular (and with the best trajectory)
since popularity leads to other advantages. Choosing rails now, for example,
would not make sense.

~~~
ttty
If you do front end, just learn node. Both are js. Plus you can share code. 2
in 1.

~~~
uyuioi
The lack of structure in node is really bad for beginners.

~~~
heynk
While it is harder to actually do something, node helped me understand how web
development "really" works. I started with Rails - I could put a simple app
together, but I had no idea how it worked. It wasn't until I worked with node,
where I had to do my own routing, controllers, models, database connections,
etc, until I finally could understand what was happening under the hood in
Rails.

------
elliotec
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/](https://www.gatsbyjs.org/) Do a bit of
research, learn what you think you need to get shipping, and ship.

------
pier25
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.

~~~
xhkkffbf
Please go into some details. I'm on a committee evaluating firebase and I'm
curious how it fails at scaling.

~~~
pier25
The biggest pain is that both DBs are extremely limited. You can't search for
example. No joins, relations, or anything remotely fancy. There are some very
very basic filtering capabilities but other than that you either load all the
data in the client and do your work there, or you use a proxy (cloud function,
node server, etc) and lose realtime and sync. Or maybe use Elastic on top [1].

Most of your Firebase logic will live in your client(s). If you have multiple
clients (web, iOS, Android, etc) you will have to write and maintain the same
logic multiple times in different languages. And since the DBs are so
barebones you will need _a lot_ of logic to read and write. Pretty much all
the business logic you'd have in a server will be in your client(s).

You also have cloud functions which have the worst dev experience I've seen
with serverless. Deploying takes forever, sometimes as high as 2-3 mins, and
you will need to deploy very often as most of your functions won't run locally
[2]. Debugging is done via the Firebase console which is a painfully slow
Angular 1 app.

For websites the complete Firebase SDK is 215kB gzipped and you will need most
of it [3].

You can define database rules using a JSON-like language for permissions and
schema but it will get super messy as your project grows and become
unmaintainable.

Unless you are doing a small project or a prototype get as far away as you can
from Firebase.

If you do need a serverless DB look into Fauna DB which gives you everything
you expect from a serious DB. Or if you're looking for a zero-config backend
look at Hasura like I've mentioned earlier.

[1] [https://medium.com/joolsoftware/extending-firebase-with-
clou...](https://medium.com/joolsoftware/extending-firebase-with-cloud-
functions-elasticsearch-129fbbb951e0)

[2] [https://firebase.google.com/docs/functions/local-
emulator](https://firebase.google.com/docs/functions/local-emulator)

[3]
[https://bundlephobia.com/result?p=firebase@7.14.2](https://bundlephobia.com/result?p=firebase@7.14.2)

~~~
noahtallen
Another issue is environments. It is generally a good idea to have a non-prod
database agains which to test new queries and changes. This is impossible with
firebase/firestore without some hacks. In a previous job, we had two entirely
separate firebase projects, one for dev and one for prod because it became
untenable to test new database structure and changes against the prod DB.

~~~
databrecht
Good to know in that case, that you can create as many databases as you want
in one FaunaDB account and even create databases in databases (parent keys get
access to child databases) and probably won't get these issues. e.g. I run
integration tests and create/destroy a child db for each test suite.

Disclaimer: I'm a dev advocate there so I'm obviously biased

------
thorwasdfasdf
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.

------
camhart
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.

~~~
amardeepsingh
If you have enjoyed AWS serverless, then I would strongly suggest you to check
out Firebase. I myself started with AWS and have now completely switched over
to Firebase now. 10x more enjoyable. Firebase just brings the right tools at
one place and makes using them super easy.

------
jaeming
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/](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.

------
inapis
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.

------
Goldar
There are so many helpful responses ITT, thank you all, you've saved me from a
ton of time wasting/rabbit holing.

I've decided to press ahead with plan A and complete the front-end dev track.

Then I'll choose a project, spec it out as best I can, and choose from Hasura
or Firebase as back-end solutions.

------
seangrogg
> [...] 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.

------
sixhobbits
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

------
alexbanks
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.

------
amardeepsingh
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.

------
headcanon
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.

------
julianeon
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.

------
thelazydogsback
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.

------
Scarbutt
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.

~~~
pier25
> SPAs are a lot of work to get right

I agree. It's trivial to render a component based on a route change but there
are so many little problems and moving pieces after that.

I've been doing SPAs for 5-6 years and for my current project I've moved to
SSR + hydration with Svelte.

~~~
el_dev_hell
What are you using for SSR with Svelte?

~~~
pier25
I'm using Cloudflare Workers but I made a little demo with Node and Fastify
here:

[https://github.com/PierBover/svelte-ssr-
example](https://github.com/PierBover/svelte-ssr-example)

------
Jugurtha
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.

------
elliekelly
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.

------
xupybd
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.

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

Thanks for the suggestions, I'll give it a listen on Audible.

------
talmr
IMO, I'd use only firebase auth and chat personally.

Firebase auth is supremely easy to implement, and you can write your own
backend services (in node, rails, Go, whatever) and auth your clients against
it using the firebase sdk. Chat makes it supremely easy as well for simpler
use cases, and if you do find it limiting, you can always swap it out for
something better suited.

In my case, I use firebase client sdk on mobile (react-native) and web
(react). My backend (go + node) services use firebase admin sdk to
authenticate requests, and my database is postgres.

------
royletron
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.

------
cpursley
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.

~~~
ficklelife
+1

I am also doing what OP has proposed (to start a business more than learn
technical stuff but I enjoy both and need to do both), I evaluated firebase DB
but ended up coming to the hasura/GraphQL/Postgres conclusion also. It’s been
pretty good, have embraced 3factor app arch and been moving quickly. I do use
firebase auth

------
uyuioi
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.

~~~
gt2
Why not do use django or rails for auth with JWT/token based auth recommending
to use them for the other parts?

~~~
uyuioi
Considering OP states he’s not proficient in the backend. Leave auth to
google. It’s just a middleware in Node so not a huge issue.

------
musicale
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.

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

~~~
uyuioi
I don’t believe that is true anymore. At one point they were many years ago.

------
Kassius509
I'd recommend using DynamoDB for your database.

Best of luck.

