The Holy Java

Building the right thing, building it right, fast

Archive for December, 2015

A Costly Failure to Design for Performance and Robustness

Posted by Jakub Holý on December 6, 2015

I have learned that it is costly to not prioritise expressing one’s design concerns and ideas early. As a result, we have a shopping cart that is noticeably slow, goes down whenever the backend experiences problems, and is a potential performance bottleneck. Let’s have a look at the problem, the actual and my ideal designs, and their pros and cons.

We have added shopping cart functionality to our web shop, using a backend service to provide most of the functionality and to hold the state. The design focus was on simplicity – the front-end is stateless, any change to the cart is sent to the backend and the current content of the cart is always fetched anew from it to avoid the complexity of maintaining and syncing state at two places. Even though the backend wasn’t design for the actual front-end needs, we work around it. The front-end doesn’t need to do much work and it is thus a success in this regard.

Read the rest of this entry »

Advertisements

Posted in SW development | Tagged: , , , | Comments Off on A Costly Failure to Design for Performance and Robustness

Why we practice fronted-first design (instead of API-first)

Posted by Jakub Holý on December 6, 2015

Cross-posted from the TeliaSonera tech blog

Alex has introduced us to the idea of front-end first design: You start by creating the front-end (browser) code. As you discover data or API calls that you need, you mock them. When the UI stabilizes, you use the mocked APIs and data to create the backend with exactly the functionality and exactly the data needed by the UI. The end result is a simpler application.

We are trying to adopt this as our approach because it is so sensible. Whenever we work with an API that wasn’t designed with the actual client needs in mind, we experience unnecessary friction and have to do various workarounds and adaptations so front-end-first absolutely makes sense to us. (E.g. when working with a REST API designed in line with REST principles – but not with our needs, resulting in a too chatty communication and more complex code.)

Of course there are same limitations. It is more challenging when you need to support different clients. And you need to take into account not just what the UI wants but also what is reasonably possible in the constraints of the existing system. You want to avoid a big gap between the two – we still remember the pain of integrating OOP and relational databases and the complexity of pitfalls of Object-Relational Mappers such as Hibernate, that try to bridge the two.

Conclusion

Fronted-first design rocks (for us). Try it too and see whether you too get a simpler application code and shorter time to market.

Posted in SW development | Tagged: , | Comments Off on Why we practice fronted-first design (instead of API-first)