I just wanted to say thank you for your work. The straightforward docs are some the best in my opinion when you want to go from "How do I do ..." to answer.
I ended up using Javalin with Kotlin and SQLite to build my wedding website.
Most of my projects are lucky to see the light of day, but with a very persistent project manager and a simple lightweight framework, I was able to ship a fantastic product with very little fuss.
I can see how DI will be overkill for a wedding website and Javalin/jdbi/sqlite is more than enough but for most business applications written in Java you really wish you had started with DI. Any DI libs you recommend for working with Javalin?
Yes, disagree on needing a library. The way your comment was worded made it seem to me like you were saying all serious Java applications need a DI library, I'm sorry if I misunderstood you. I prefer doing my ID manually, so no recommendation :)
It took me a hot moment to adjust after leaving classic spring Java land to a Scala shop that doesn’t use DI framework, but now I love it. I agree with what you said.
It does help to keep services small so the manual DI arg passing doesn’t get too spread out and boilerplate-y. But I have worked on a dozen services here and don’t miss an automatic DI framework.
> Calling a constructor is DI. ‘new’ is the only DI framework required.
This feels like the sane thing to do, but sadly for historical reasons this won't work with many (if not the most) Java frameworks out there, or even certain options in the .NET ecosystem.
When you get non-trivial frameworks that are deeply entrenched in having DI and using it internally for a bunch of stuff, you'll find yourself out of options, e.g. if you use Spring/Spring Boot.
And in many places something like Spring Boot might be considered an "industry standard" and you might get looked at funny if you suggested using another framework, even more so if they have their own configuration/plugin/utility solutions for it already built within the org.
Personally, however, I rather enjoy alternative takes on how web frameworks could look and even something like Dropwizard/Vert.X/Quarkus have nice quality of life aspects to them.
In a sense, it's nice that the industry is moving towards smaller service based architectures, where you might spin up a new service with whatever tech fits the problem that you're trying to solve, as opposed to being locked into adding code on top of some bloated monolith (though that comes with certain tradeoffs and drawbacks, in regards to complexity and maintenance).
I have a few questions about this approach, cards on the table I mainly deal in C# where DI (through the framework) is the default. How do you manage the initialization of all of the dependencies? Do you need some sort of "root" where everything is initialized and passed in? That was all I could come up with while keeping it testable and that doesn't sound maintainable once you build up the number of dependencies.
I'm also a fan of the manual DI approach - I strongly dislike the magic.
I think it helps if you are building test/fakes of your deps that don't really need as many sub-dependencies. Generally you in a test `@BeforeAll` construct a bunch of objects or for a program you do it in `main`.
I did work on a project while I was at Google that was really big and a decade old that instead had a class with a bunch of lazy getters for each item in the dependency graph, then tests would override or reset the getters with testing versions as needed. It was a little clunky but I preferred that approach over the projects I worked on that used dagger.
If you've read through the Dagger dev-guide [0] there is *a lot* in there, while the manual approach it's usually just `new` which is a really simple concept on it's own :) I think this is the right tradeoff because reading code is harder than writing code, so it's worth the extra setup. In practice I haven't seen it to amount to be an overwhelming amount.
What dependencies are multiplying? I organize my code so that the very top level of the api has all external dependencies injected there, there is no public classes below a single exposed class that would need to be directly injected into. The only thing I need to actually inject are things that are outside of my memory space, ie network calls, event buses, dbs. If it's not using something outside of my memory space I am just using new inside my classes, it's far easier to test.
For example, if I'm adding a new feature to allow a user to change their address, I would have a single class at the top level "CustomerAddressChange" or whatever. I would inject an interface that wraps everything external, and that is the only thing that anything would be injected into. My tests would all stub only that interface. Everything else is done without any sort of DI container.
When I switched from Java to Go and started doing DI like this, I was amazed at how simple and efficient DI could be. I was taught DI with Spring and never fully grasped why and how it worked. With Go it just clicked and to this day I still have no idea why DI libs are so complicated. If I ever come back to Java, I’ll make sure to do DI manually.
For anyone who wants to get started with this stack you can do `git clone https://gitlab.com/asad-awadia/kotlin-server-app.git` to get a full maven project with javalin, sqlite with ktorm and jdbi everything setup
Similar to other use cases mentioned already, it was a way for us to create a privacy-focused site to manage guests and give guests the opportunity to update their RSVP, dietary needs, and requested song for the DJ. Additionally there were a few sections of the site where my fiancée could update content as she saw fit by logging in and hitting save. We found the database useful to keep track of RSVPs, gifts, and who we still needed to send thank you's to after the event.
The main drawbacks were people who are not comfortable using the web and people remembering their unique adjective-noun passphrase. Also, I'm not very savvy when it comes to CSS or design so my giddiness was crushed demoing what I thought was the MVP to the "project manager".
I don't want to detract this from being about Javalin though. It's fantastic. I would recommend it and use it again for projects.
Re: pass phrases, my go-to for projects like that is to put a unique hash or something in the URL for each different person. The experience for users is that there's no password to remember or anything like that. They're not going to remember the URL anyway.
You can put the hash in a #xxxx part of the URL so it doesn't show up in logs if thats important to you. The downside is you need to give everyone their own URL (maybe via a QR code on a paper invite). But you already had to give everyone a pass-phrase so whatever :)
It's been SOP for some time (at least 20 years) to use an RDBMS to store your site's content and write a stateless application server to pull data from it and compose a response. Call it the "CMS pattern".
Static site generation, and a few other ideas, challenges this basic pattern, but most of the worlds applications use it. Javelin is trying to make the pattern better on several axes, simplicity first-and-foremost, and not replace it.
Funny, I had a LAMP stack in mind while writing it, and more specifically WordPress. For all the enterprise Java webapps out there, I bet there are 1000x more php sites. And they all use the same basic cms pattern.
heh, very good point. WordPress is absolutely everywhere and is exactly this model. I think WordPress forged the path too, so definitely deserves the "blame"
I used PostgreSQL for my wedding website. People could RSVP, say how many were coming, volunteer for support roles since we did too much of it ourselves, etc.
For a website, the question should be why not use SQLite.
Given the various compelling and (by now, here, I hope) well-understood advantages, it should be the default choice. Certainly for a site expecting hits in the mid-hundreds, total. Maybe ten simultaneous connections the day of?
Interesting, I interpreted the question completely differently, i.e. why use database at all?
FWIW, I'm not in the web app world, so my wedding website was a single page HTML; not a single page app, let alone a content management system - I googled something like "Wedding page HTML template", then grabbed a HTML template from w3schools, opened it in notepad, and put my own words and IMG tags. It looked pretty, was "responsive" by default, took very little time to create, and worked solidly.
I'm sufficiently old school / ignorant / pragmatic / lazy / focused / something, to wonder why complicate a wedding page with anything else :-)
(I mean, I'm old and ignorant and simple enough that I keep misinterpreting what "static site generator" is :P )
Interesting, I interpreted the question completely differently, i.e. why use database at all?
Maybe the wedding page has forms, needs to store data and author is most familiar with Java or maybe they are getting creative and are calling third party services for convenience, lots of reasons. A simpler solution could be nginx/cgi and a local file for the DB, or cloudfare workers(you can render HTML from them) and their key/value storage.
Yeah that was what I meant but everyone else seems to be commenting except the person I was replying to lol. I am not attacking databases I am just wondering what they used it for on a wedding website.
I ended up using Javalin with Kotlin and SQLite to build my wedding website.
Most of my projects are lucky to see the light of day, but with a very persistent project manager and a simple lightweight framework, I was able to ship a fantastic product with very little fuss.