I’ve been a developer for 3 years. I have joined big companies with a legacy codebase and have never built something from the ground up (with the exception of toy projects on my own time).
I want to build an open source web app that scales. Where would a lead engineer start in thinking about this – start building the back-end first?
I like to start with the front end because I can focus on the user experience and then I implement the backend to what I need to achieve the UX I want.
I don’t think there’s an absolute “right” way here—it’s really about your comfort.
@tio407 Personally I think that’s like asking if should someone start from writing tests at start. It’s not like that only TDD is good way and same goes to your question. You can even think about front-end like a real tests for back-end and it would work similarly to TDD.
If there is more than one good way then it of course depends and you need to think why it depends i.e. what are the cons and pros. The only one who knows it (at least first) is you. Even if you can see exactly one good way then maybe think if you did not missed any other. Computers at end understand only 0 and 1, but it’s not working same for developer. You need to ask questions … lots of questions …
Even projects with similar budget and functionality can be developed differently. For example in one company you could be asked to create front-end first (only CSS and HTML) to visualize how your product would work in order to discuss with client all project details and provide estimates for each part and whole project. In other company back-end may have priority as front-end is changing often. In such case you would need a really generic and stable back-end in order to introduce enhancements (not new features) really quickly in order to focus on front-end look and like with client. Finally last company would work on both sides at once as it may be the fastest way to introduce new features quickly.
At start I’m not working on any of them. First what I’m doing is as said ask questions. I’m creating md files with a detailed plan. With a plan I’m able to create a simple forms in order to visualize how project would work, if I did not missed anything, how to split work in parts and what I need to achieve for each part (for example slack integration). Finally I would slowly work on each part in both backend and frontned, so in my case I would firstly plan and then work on both at the same time.
It’s also a bit similar to question: What is a good way to learn Elixir?. Basically you learn in your own way and answers are probably boring, but always to the point i.e. practice. Here it looks exactly same, but instead typical tip would be something like ask yourself. Well … at end everything goes into practice, so even if you would follow not the best way then by simply practicing you would slowly see what you can improve. Once you notice them you just need to ask how to improve and finally again at end you would have practice again. 
You may be confused and ask why, but the answer is simple … Every human is learning to the end of life and learning means … PRACTICE - it’s ours Rome 
I do agree with @Eiji that practice is extremely important and you should always do it.
Maybe create two extremely small projects, start one with the frontend and the other one with the backend first and see how you feel about both ways.
My experience:
I would start by building a front-end mock up. It gives me the chance to shape my idea and logic quicker than when dealing with code only/backend. If I start coding, it’s easy to add extra functionality that I won’t need, or write my logic in a way that doesn’t work well with the frontend later on. Once I know what and how I want to build, I start building it. This will save me time and effort.
You helped me re-frame the problem in a better way. Thank you.
I start with the backend because I know what data I need to store, but not necessarily how the interface should look yet until I test it thoroughly with others, and having a backend with data that I can actually work with means I can play with the front-end more to find the better style.
I also start with the backend, but not fully fleshed-out. I’ll get the schemas and db tables in place and then switch over to get the front-end layout roughed-in with a fairly clear sense of the data output that will be included there.
From there, I’ll go back and forth module by module, getting more and more live data into the templates and refactoring my layout chunk by chunk.
There are lots of ways to do it. Personally, I typically don’t think about front-end vs back-end, but rather think about what is the smallest feature I can add to make it useful and the ship and deploy the entire stack (front end, back end, server, etc).
For example, if I was going to create a forum like this one, I might start with making a forum that only has one thread and people can post messages and read all the messages in the thread, without user accounts, multiple threads, moderation, etc. Then I’d deploy it to production before thinking of the next most important feature.
Good question 
. I like to think about it as in music. The words or the music first? Both approaches work but they each affect the end product in a different way 
The aim is to have clear DataModels…
I first create basic frontEnd UI or at-least on Pen n Paper. Try to come up with a few data set variation examples… This helps in thinking about models and structs…
Next I create simple structs and the tests… Once used to directly generate migrations and create Ecto Schema and database tables and keep modifying, but now I play around with structs first… modify and come close to some stable dataModels… then will generate the Ecto Schema…
Not everyone will like this, but it helps me… I have function like User.new_random or Post.new_random and play with these in console and tests…
Personally, I’d start with whichever would bubble the most unanswered questions to the surface of your problem domain.
If you know most of the shape of the data you will be accessing/storing, build out the frontend first to discover novel ways to interact with it.
If you know mostly what user experience you want, build out the backend first to discover surprising constraints your UX expectations enforce on the data shape/validation.
If you know neither, your project needs specification before development, tackle whichever is easiest first to inform the more complicated half’s development.
Personally, I’m an EventSourcing/DDD junky. So I don’t write anything until I understand my problem and start fleshing out my domain. From there, I discover the events that make sense for each use-case. Only then do I start implementing stuff command by command.
So I guess my answer is that I’m a backend first kind of guy. If I get it right – and this takes many many iterations – the front-end possibilities are endless.
If building the project with an API I don’t start from neither of them.
First of all I need to define my API specification in order I can use it later as a contract between the frontend and backend. This approach saves me countless bugs and hours of development, because I catch failures in my approach while doing the specs.
To build the API spec we can use RAML or Swagger.
But do a favor to yourself and first read the ebook Undisturbed REST.
Usually, I start by “steelmanning” my understanding of the problem from the perspective of expected functionality, and then move to the back-end design by being as conservative as possible. Conservative in the sense of factoring as much as possible, abstracting into libraries, and building functionality as required. A significant number of past projects involved user functionality that was not available except when the full system was running (I come from the cyberinfrastructure side), so having critical tests of corner cases was a must. In my view, coding should start once the ideas have been sufficiently debugged. Debugging ideas is cheap, debugging poorly designed systems is incredibly expensive.
I also like to build the backend first. I like to reason about the business logic, data layer, etc. first, and then find a good way to present that to the user. I might think about the interface in my head during that process as well, but I never star writing front end code without the backend to back it up 
© Copyright Elixir Forum | Terms | Privacy & Cookies
