DEV Community

Cover image for Do you start with frontend, backend, or both?
Madza
Madza

Posted on

Do you start with frontend, backend, or both?

When it comes to developing full-stack apps, what is the preferred sequence of your workflow?

Do you normally start with design and user interface or all the server stuff and databases? Or do you like to do both simultaneously?

Discussion (31)

Collapse
bobbyiliev profile image
Bobby Iliev

I would personally suggest a little bit of both and then you transaction into the one that brings you more joy. If you end up linking both, that's even better.

I would also add DevOps to the list. Frontend vs Backend vs Fullstack vs DevOps, just created a poll for that:

twitter.com/bobbyiliev_/status/139...

Collapse
joelbonetr profile image
JoelBonetR

apart of being more an infrastructure thing, DevOps is something you usually don't start with, the reason is you need to understand the dev process to ensure a fluent software transition from dev to test/prod environment.
So it's something that usually devs do (that's the Dev in the word) on small/medium teams and that only largest teams or companies with complicated (most of time over-engineered) builds are in need to specify this role on a person or two.

The other part is SysAdmin's stuff (when the code reach the desired stage it must work well with a well defined and profiled server, it's monitoring and so), but you're a sysadmin so you know what i'm talking about.

At the end all devs need to be a little "full stack" to understand the entire process if you expect to do something else apart from coding little pieces of code inside a software you don't know at all. Maybe i'm seeing that from an engineering point of view and this can be avoided for self-learners and newcomers but I would recommend it as well as I recommend to push hard into knowing the environment where your code is running (for a web dev: JS engine, DOM and CSSOM, compilers, interpreters, networking, different servers and what they offer, how to set up a simple env and so) so you can build better code.

Collapse
aghost7 profile image
Jonathan Boudreau

apart of being more an infrastructure thing, DevOps is something you usually don't start with, the reason is you need to understand the dev process to ensure a fluent software transition from dev to test/prod environment.

Oh? What if a feature has a perfect use case for serverless? Thinking about infrastructure up front has huge benefits because you end up with a better architecture.

Thread Thread
joelbonetr profile image
JoelBonetR

Having a better architecture is that one that fits better into your project, so if you're developing a serverless app you'll know how to take care of the desired and required software needs.
But wait... you know that serverless does not mean "without server" on a literal way, do you? xD
It's an execution model where the provider (AWS, Azure, Google Cloud...) is responsible for executing fragments of code while dynamically assigning resources.
While serverless abstracts the underlying infrastructure to the developer, the servers still participate in the execution of our functions.

By this means, it's still infrastructure but you subcontract a provider to be "your sysadmin".

Apart from that I understand that one of both (you and me) made a mistake (me writing or you reading).
When I said "DevOps is something you usually don't start with" I mean when learning to be part of project development process for the first time. If you know nothing or few about how do you would manage to find out which architecture do you need? And moreover, having a serverless, or a cloud, or a VPS or having Apache, or Nginx or whatever server you need in the architecture is not part of the Dev on the DevOps.

As said 90183710273 times, DevOps is a blend of practices and not a job, some parts rely on Devs, some parts rely on Ops. I wrote a detailed post about that some time ago:
dev.to/joelbonetr/all-you-need-to-...

Please, tell me if you find out any inconsistency.

Thread Thread
aghost7 profile image
Jonathan Boudreau

Having a better architecture is that one that fits better into your project, so if you're developing a serverless app you'll know how to take care of the desired and required software needs.

Building an application which is entirely serverless isn't the only use case.. IMO the best use case for serverless is when you have ad hock operations which need to be handled, such as indound emails, periodic jobs, etc. This is because these operations are short lived and don't necessarily need a server of up at all times.

These kinds of decisions affect how the code is implemented as well as the infrastructure costs. It is better to consider them sooner than later.

But wait... you know that serverless does not mean "without server" on a literal way, do you? xD

Yes I am aware.

As said 90183710273 times, DevOps is a blend of practices and not a job, some parts rely on Devs, some parts rely on Ops. I wrote a detailed post about that some time ago:

I am also aware of this. I did not speak of devops, I spoke of the infrastructure. Not thinking of the infrastructure as part of the development process is antithetic to devops.

Thread Thread
joelbonetr profile image
JoelBonetR

did you just avoid the context of "newcomers that start learning to code" another time?

Yes I've used "serverless" with Google Cloud Functions for example and yes it was about triggers when calls came into the switchboard on a specific company but... Holly cow! It seems an add to serverless more than a reliable comment about a topic. Please read the title of the post and understand the context where we are discussing in.

Thread Thread
sharpninja profile image
The Sharp Ninja

I'm not convinced that anyone should ever plan on serverless as an architectural requirement. A more general pattern, such as Mini-Mon should be explored before making such a decision.

Thread Thread
aghost7 profile image
Jonathan Boudreau

Nothing in your previous comments suggests "newcomers that start learning to code". You speak of working with teams and learning the development process, which sounds more like starting a your first company to me. I don't disagree that if you're starting to learn how to code, you should probably focus on that instead.

Collapse
andreidascalu profile image
Andrei Dascalu

When you say "Frontend vs Backend vs Fullstack vs DevOps" it's actually not devops, it's just ops. Devops is a practice that brings all areas together.

Collapse
bobbyiliev profile image
Bobby Iliev

True. But you could still be a DevOps Engineer right?

Thread Thread
andreidascalu profile image
Andrei Dascalu • Edited on

Depends - any engineer they in a team that practices devops is theoretically a devops engineer (regardless whether you do backend or ops or something else). Ken Mugrage (kenmugrage.com/), one of the guys who helped coin and define the term (though not the originator or the idea) always goes at great pains to emphasize that devops is a practice and not a role (still doesn't prevent recruiters from using it as a synonym for ops, as it sounds more modern)

Thread Thread
bobbyiliev profile image
Bobby Iliev

Very good points! I guess that I was going with the trend but you are right that the question should be rephrased to Ops or SRE rahther than DevOps.

Thread Thread
joelbonetr profile image
JoelBonetR

Roles in project development career path simplified:

  • BackEnd
  • FrontEnd
  • SysAdmin
  • DBAdmin

Then you can invent jobs specialised in a single thing such "test engineer... is someone who writes down tests" (ok but usually devs should write them so...) you can even go deeper and say "front end test engineer".
The same happen with DevOps and other stuff.

The only role that is not so common as it's needed to be in the industry is the person who design into HTML+CSS (layout designer).
The issue here is most of time this people studied and worked with design but not specifically with web design (or software UI design) so you need someone to translate it's designs (most of time made in Adobe XD, Sketch, Illustrator, Photoshop or something worse) into code.

This is a harmful process that burns devs who pick this job and the designers who are designing products-for-code without coding knowledge.
One role feels like he's hitting a silly wall that does not understand how the things work on an engineered product and the other feels like it's own creativity is melted down.

This does not happen with other engineered products such a car, on which a designer will make a concept and then the engineers will modify to match the required specifications. On the other hand, in the IT world seems that engineers have to apply a design without further analysis and modification so it harms performance, usability, SEO and much more.

just a thought, i'm back to work :D

Collapse
cjpartridgeb profile image
Chris Partridge • Edited on

We generally build most of our applications around PostgreSQL, so I always start by defining a rough data model (after going over business/workflow requirements with those involved) so I can start fleshing out a database schema via migrations (tables, views, triggers, functions, etc).

After that I'll create the entities to interface with the above - which are then used to construct services containing the core business logic. In most cases we're exposing a REST API, so I'll then move onto defining routers, middleware, input validation and other HTTP related stuff (e.g. cookies, output serialization, etc).

Depending on the complexity of the UI/UX, we may have someone working on specific components before the above is ready - but I've always found UI developers to be more productive when they have a concrete API to interface with.

The initial "MVP" is generally very loose in terms of validation and work flow, but will be tightened down as we iterate and receive feedback.

That being said, we're a small team that likes to spend less time planning every detail in favor of getting something functional in front of the client so we can start iterating towards where we need to be.

I've lost count the amount of times we've spec'd out projects to the nth degree (based on requirements from many meetings), only for the requirements to be switched up when it finally gets into the hands of the actual users.

Collapse
joelbonetr profile image
JoelBonetR

Are you running high performance software? If the answer is no I also would like to know why don't you use an ORM, just out of curiosity.

I used to work with data first many years ago but it seems it's all code first nowadays.

Also forget about REST and embrace GraphQL, you'll be happier (and any other involved dev too)

Collapse
cjpartridgeb profile image
Chris Partridge

When I mentioned 'defining entities', this could be an ORM entity - however it could also be a custom entity using Knex query builder under the hood - all depends on the project and the complexity/requirements.

As I mentioned above, we lean heavily on PostgreSQL (along with PostGIS), so we generally steer clear of using any ORM to 'define' our data model.

I'm a big fan of Objection (pre-TypeScript), and now MikroORM (TypeScript) - both of which are built on top of Knex (which I've been using and loving since it's inception).

I really like the use of the Unit of Work/Identity Map patterns bound to a request context with MikroORM though - certainly gives it a leg up over TypeORM/Primsa in my opinion.

And yes, we've been watching and playing with GraphQL too (PostGraphile & Hasura in particular due to their favoring of PostgreSQL and PostGIS support) - however it's a complete paradigm shift and there are certain edge cases in many of our projects that aren't very conducive to GraphQL (although things could have changed, it's been a few months since I've last used either of the above).

But GraphQL is certainly on our radar :)

Thread Thread
joelbonetr profile image
JoelBonetR

Oh, my bad, with "I always start by defining a rough data model" I supposed you were working data-first, which I've to mention that this is not bad, you can profile your DB better this way and then perform migrations from DB to code instead the reverse way.

For the GraphQL and your edges... well you don't need to use the same stack for the entire project, that's the fun in services/micro-services, that you can build each one with the tools you feel better for the job :D
You can create a dataLoader for those cases and resolve pointing to a REST if this fits better to you (for example)

Collapse
madza profile image
Madza Author

Looks like a well-thought-out system 👍😉

Collapse
jmdejager profile image
🐤🥇 Jasper de Jager

I like starting with the frontend. Making some mock data and changing it on the fly when you see something else is needed just keeps you going.

Not a big fan of "guessing" what dat should be needed and creating the frontend after.

That being said, some functionality is just backend functionality. Making an export for example with a simple button and some settings in the frontend I'd start with the backend probably.

Guess it has to do with how backend oriented the feature is but my default is frontend first 🙂

Collapse
jackmellis profile image
Jack

I usually start with the front end and have the user journey drive the requirements. Then build the back end, knowing what data the front end needs already, and then everything meets in the middle. At least that's the theory.

Although, this is just in terms of personal / solo projects. At most of my jobs the back end is written first because the UI is often an afterthought in the planning stages 👀

Collapse
madza profile image
Madza Author

At most of my jobs the back end is written first

Casual case especially for enterprises, where the business logic and data flow comes first 😉

Collapse
andrewbaisden profile image
Andrew Baisden
  1. Design it in Figma
  2. Create the back-end
  3. Create the front-end
Collapse
madza profile image
Madza Author

Solid approach 👍😉

Collapse
sharpninja profile image
The Sharp Ninja

I start with a data model which I normalize to fourth normal form. Next I create POCO entities from the datamodel and generate a dbcontext with EFCore. I push the migrations to an Azure managed SQL instance and use xUnit to build basic CRUD test cases to both seed test data and test the correctness of the data model.

Next I mock up the main use cases either in html or xaml depending on web or app. After building enough screen mockups to represent the workflow, I start creating APIs to expose the basic workflow's data flow. I define models for each API and thrn consolidate them such that a model with multiple fields in common with multiple API encapsulate the repeating fields in an abstract class and a sub-class for each API is created. Then I create the service endpoints and unit tests for calling the endpoints directly and indirectly through the API. Next I create Adapter patterns to translate models to entities which are consumed by the API implementation. At this point I begin integation testing by mocking the dbcontext and using an in memory data store, allowing a precise and repeatable testing experience.

Only after I have a first round of functioning APIs do I start implementing UI,, wgich at this point should only require hooking up UI elements to models and responding to events appropriately.

Collapse
jwhenry3 profile image
Justin Henry

This is a flow I typically fall into depending on the scenario:

  • Do I need a robust backend architecture
    • Plan out the backend first so I have a scalable solution
    • Build out the frontend to facilitate the backend functionality
  • Do I need a robust frontend with a simple backend architecture
    • Build out the frontend, use Firebase as the backend storage solution until I need more
    • If an authoritative server is necessary, introduce NextJS or NestJS with appropriately provisioned endpoints or mechanisms to facilitate the needed features.

Depending on the app needs, most of the time I would lean on frontend-first, just because you can worry about the server side integration much further down the road.

Collapse
andreidascalu profile image
Andrei Dascalu

Depends. They usually start in parallel with one "side" being more involved in api design. We have projects where the UX trumps anything else so there the front-end also has a greater say in API design as well. There's always some senior architect acting as a consultant and bridge.

Collapse
cmuralisree profile image
Chittoji Murali Sree Krishna • Edited on

I like to choose frontend first then I will pair with backend simultaneously, each section or page will be paired with its own function, I guess this will be faster way to create a big projects like e-commerce or other stuff

As usual I might be wrong

Collapse
chaos0815 profile image
Christian Wolf

You start with what the user needs / makes money. In most cases that would be frontend.

Collapse
aghost7 profile image
Jonathan Boudreau

I focus on features, so all of the above.

Collapse
jashgopani profile image
Jash Gopani

I prefer to do maximum backend first because it is then easy for me to build front end