51–60 of 108 posts
Also found there to be a motivational aspect to this. Since I can't push the buttons or turn the knobs because its just UI at this point, I can't help but breathe life into it so that I can actually use it.
I'm going to disagree with both approaches, and suggest (for lack of a better term) "middle-out". Always define the API first . Figure out the information necessary, and make sure it meets both front-end constraints (e.g. no information is missing, does it need to be one call or multiple calls, etc.) and back-end constraints (can this be efficient to retrieve from the database, does one server have all the info, etc)…
For instance if on the frontend you need to display an infinite list of items, how you get your data can be heavily influenced by your interface. If you plan on having a super fast scroll with the user flying through the items, you might want to do it differently than for a page by page site.
If you design API first you must make this choices upfront, and you paint yourself in a corner if you change opinions when the resulting UX is in your hands and you’re playing with it.
If you’re prototyping greenfield product, it’ll morph many times as you build it. Once you’re happy where it is, and you’ve stabilized on data structure (not database schemas), then just start replacing mocks withr your API calls. Acceptance tests will tell you if you’ve done it right.
Always 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…
Anything else is ephermal.
History is littered with millions of enterprise software that can't beat the simplicity of a spreadsheet or the flexibility and efficiency of a unix command line
isn't everyone building front to back? You firstly establish a purpose of your solution. Thinking the job to be done, the users, the features.. Then you do a design. Likely you have a design team, that does research and creates wireframes or high fidelity mock ups. Then you establish requirements for the various layers in your stack. So what I described is a fairly typical process. It is front to back. I can't imagin…
There are plenty of reasonable ways to build web applications. If the process you described works for you, that's great, but others do find different strategies effective too. For example, your process puts great emphasis on the visual design. To me, that aspect is almost entirely orthogonal to the software design. That's not to say it isn't important to getting a good end result, but once you know what interactions…
Always 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 agree, though I generally reduce this question to, "what is the shape of my data?".
I'm going to disagree with both approaches, and suggest (for lack of a better term) "middle-out". Always define the API first . Figure out the information necessary, and make sure it meets both front-end constraints (e.g. no information is missing, does it need to be one call or multiple calls, etc.) and back-end constraints (can this be efficient to retrieve from the database, does one server have all the info, etc)…
Sometimes that approach leads a project into a cemented API and new requirements that arise after real world application can be even harder to implement as a result.
So I guess I’m not arguing, but agreeing while adding that the approach needs a couple qualifiers.
I think going in either direction is gonna have flaws. Sometimes frontend informs the backend (rich user flow -> data dependencies) and sometimes backend informs the frontend (often suggesting more composable and maintainable designs) I've worked on projects that were very front-to-back and without having a constant eye towards the backend, the UI requirements would have ended up dictating a non-composable, non-exten…
The trouble comes in keeping a clear idea of what an iteration is supposed to test or accomplish beyond "makes it better" - and an end-to-end iteration is expensive. That is where the idea of putting the data model or UI "first" develops, since it lets you build from the technical details towards the concept, as a way of constraining and filtering your thinking.
Something I want to try but have not gotten around to willfully doing, is to treat the initial design stages as an exercise circuit of focusing on each layer for a limited period of time each day, rotating from one to the next.
I'm pretty sure that you could get some great results if a work week were spent doing a four hour cycle, with one hour each thinking and researching data, interfaces, UI, and premise/market.
I'm going to disagree with both approaches, and suggest (for lack of a better term) "middle-out". Always define the API first . Figure out the information necessary, and make sure it meets both front-end constraints (e.g. no information is missing, does it need to be one call or multiple calls, etc.) and back-end constraints (can this be efficient to retrieve from the database, does one server have all the info, etc)…
If this is the case then you should develop the plugins first.