How do you build your service layer first but your APIs last? Aren't APIs part of the service layer? The interesting thing about DynamoDB single-table design that I'm really starting to like is it forces you to start with API calls. I literally start with an excel spreadsheet of API declarations and corresponding HASH/SORT keys.
Build Software from Front-to-Back
81–90 of 108 posts
Re: Build Software from Front-to-Back
#82I think a highly effective strategy is an outward-in somewhat recursive iteration from high-level details towards a polished, robust solution. Of course, the first step must be some sort of sketch, however minimal or vague, of the user-facing functionality -- "user" can mean a number of things here, depending on the application -- or else you have no idea what you are doing.
Something like:
1. High-level, low fidelity sketch of the user stories and the UI
2. High-level, low fidelity sketch of a possible database schema
3. Refinement of UI and user stories
4. Mid-level sketch of possible API
5. Refinement of DB schema and backend models
6. First pass implementation the UI
7. First pass implementation of the backend (db + models + API)
... A few more iterations, bug testing, and voila! Of course, minor variations of this could also work well. For example, 6 and 7 could probably be easily switched.
Re: Build Software from Front-to-Back
#83I've got a way of doing it, where the server is basically just consisting of 4 types of endpoints:
- CRUD on table records, which makes the data schema independent
- Actions which can update multiple tables, call 3rd party etc
- Queries which can go more complex things than GET or GET list, such a search, or filtering, or sorting
- Selections, which are gets or queries run over multiple tables and combining the results
I'm addition each endpoint returns in JSON, but can have a
/with/:view
suffix attached to template that into HTML
I find this organizes well and covers all use cases
If anyone wants to see a Node template of this, it's
Re: Build Software from Front-to-Back
#84I don't think front-to-back or back-to-front are correct. From my experience, it's always from what I've seen outside-in
This means understanding the problem domain. What does the app solve? Better yet, how does the app either (1) save money/resources for the problem, or (2) generate revenue streams?
When you start from this approach, things become much more clear. Generally speaking, start with the UX low fidelity wireframes first. What are the user-stories for the user? Can they log in? Can they do some CRUD functionality relative to the problem domain?
Okay, what data does this user need for these pages? What sort of user-activity are they going under? Create a set of datatables describing the problem domain.
It needs a user table? check. It needs a license table? Just map out all the data needed, and group them into appropiate tables.
Fromo there, map out the relationships in a relational format to get a better prospective on the bigger feature
Are these features even needed according to the frontend? Okay, go from there. What is the cost to implement each feature, and how does this impact the development velocity / budget of the project? Go and find the sweet point of what's defined as a MVP, and then proceed to figure out what a stage 2 looks like.
Does the original data model have a migrationary upgrade path? Imagine if your developing the backend. Do you forsee problems running the migrations?
Now you need to think about scalability and whether that actually matters here. Changes are it doesn't for the vast majority of apps.
Do you need subscribers to aggregate bulkInsertions to the database? Do you need a redis cache to prevent unnecessary calls to database? Or do you need something more complex, because the end user is a developer and your providing a high scalable Web API service?
Just keep cycling outside-> in until you've satisfied all the results into a proper MVP database and a MVP UX pen paper design.
At this point, you'll want to define the API and how the frontend will consume it. How will the backend handle it? For instance, if you spec it graphql, prepare for a world of pain on the backend and an easy life on the frontend.
You should think about your API design, and use design patterns to think about how you can keep the frontend as simple as possible. The state of truth should of an application should live closest to its data source(s), so tread with this path in mind. Sometimes the frontend does the same work (e.g. financial calculations) to reduce the total number of calls to the backend. You might want to consider everything else here at this point, e.g. whether websockets are needed etc. And other factors in the application such as third party providers.
There's many right solutions to a problem domain, but there are just as many wrong solutions as well. Go from the business side first, and go outside-in. The best answer is the simplest one that satisfies all criteria, both in UX and how scalable it needs to be
Re: Build Software from Front-to-Back
#85I have a mindset to develop the back-end first and then go for the front-end, and I usually do in that fashion. Theoretically it reasons as right. However, I always find that when developing the front end, I inevitably have to add functionality to the back-end.
Recently I started learning ASP.NET Core Razor Pages and found it quite refreshing that the line between front-end and back-end is very much blurred and somehow, the cognitive load is much lesser, than compared to, say, and Angular + API stack.
I felt the same for some of the projects I developed using Django, though, Razor Pages is even more merged when it comes to front-end and back-end.
Re: Build Software from Front-to-Back
#86Always interesting to read how others work. I'm a backend dev who does quite a bit of frontend though I deeply dislike the current state of frontend (bring back Webforms) For me it all starts with the database, always. Code, ux, network is all ephemeral. The schema, the invariants and the data are forever. (this is also why I think microservices are often the wrong approach, you're solving a code problem at the expen…
Linus Torvalds said "Bad programmers worry about the code. Good programmers worry about data structures and their relationships.".
Here's a really interesting discussion about this quote and the idea behind the above: https://softwareengineering.stackexchange.com/questions/1631...
As a backend dev myself, I totally agree with it, but I think when we're developing full blown apps we should have the end user in mind and focus on their experience using our app more than on adopting data-driven UI design.
Re: Build Software from Front-to-Back
#87Totally agree with this. At yazz.com we take exactly the Visual Basic approach too of building software from front to back and it works for simple things
Re: Build Software from Front-to-Back
#88As a "full-stack" developer who started out on the backend and took on front-end work later in my career, I used to build back-to-front. You generally end up with a cleaner, more scalable, and stable solution. That nobody wants. I've learned this lesson the hard way. Start with the UX and work your way backwards. I don't like it from an engineering perspective, but it's the only way to go to build products. Users jus…
Agreed. I found that getting as close as possible to the user minimizes the amount of useless/superfluous code.
Front-end is pretty much as close to the user as you can get.
Re: Build Software from Front-to-Back
#89Always interesting to read how others work. I'm a backend dev who does quite a bit of frontend though I deeply dislike the current state of frontend (bring back Webforms) For me it all starts with the database, always. Code, ux, network is all ephemeral. The schema, the invariants and the data are forever. (this is also why I think microservices are often the wrong approach, you're solving a code problem at the expen…
I generally do like the data-first approach when I have a good idea of what we're building. One place I’ve found it useful to start when you don't have the views planned ahead of time is to mock up the main data management views with handwritten sample JSON data needed to render the functionality desired. Then make the DB schema to provide that data.
If you want to get fancy, you can use Mirage JS [1] to emulate network requests with mock data.
Re: Build Software from Front-to-Back
#90Build software through "meeting in the middle". Define the front (user interface), define the back (data structures), and then progress towards the middle.
After all an interface is, by definition, where two things meet and interact. There are too many unknowns otherwise.