{"id":133,"date":"2019-09-06T14:29:21","date_gmt":"2019-09-06T12:29:21","guid":{"rendered":"http:\/\/www.mbarsinai.com\/blog\/?p=133"},"modified":"2019-09-06T14:29:21","modified_gmt":"2019-09-06T12:29:21","slug":"psps","status":"publish","type":"post","link":"https:\/\/www.mbarsinai.com\/blog\/2019\/09\/06\/psps\/","title":{"rendered":"PSPS"},"content":{"rendered":"\n

At CodeWorth.io\u00a0<\/a>we create many web applications. Unless there’s a very compelling reason not to, we’re using the Scala flavor of Play Framework<\/a>, which we find performant, fun to work with, and generally easy to maintain (static typing FTW! There. I’ve said it.).<\/p>\n\n\n\n

Now, Play is a very non-opinionated framework that’s happy to work with multiple database servers, front-end kits, etc. It’s great since it provides us with the flexibility a software studio like us needs. On the flip side, though, we found ourselves re-implementing various functionalities, such as nav-bars, page layouts, and logins (including “forgot password” flow and such). The textbooks say that re-implementing functionality is wrong. That’s only partially right – when you implement a functionality for the fourth time, you’re doing a much better job at it. But enough is enough – one would also like to write some new functionality from time to time.<\/p>\n\n\n\n

Enter PSPS<\/a>. This is a very opinionated application seed. We built it by collecting our best implementations, and then cleaning and brushing them up one more last final time (hmm, actually, we could improve this a bit by…) . PSPS is based on technologies we found to be reliable, and easy to work with and extend. Nothing fancy or surprising, really: PostgreSQL<\/a>, Bootstrap4<\/a>, and Slick<\/a>.<\/p>\n\n\n\n

Out of its proverbial box, PSPS supports many features common to web applications:<\/p>\n\n\n\n