|
|
|
|
|
by vbsteven
3003 days ago
|
|
Implementing simple middleware in Spring (boot) is pretty much the same. One class with one method that has access to req, res and the next filter. The @Component annotation is all it takes to enable the filter in your web stack. @Component
public class MyMiddleware extends OncePerRequestFilter {
@Override
protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
// your code
filterChain.doFilter(request, response);
}
}
|
|
1. Set up your spring boot project properly
2. Set up all the XML that supports your beans properly
3. Know how and when to use @Component
4. Know that OncePerRequestFilter exists, and/or to extend it, which method to override
5. Know to call filterChain properly
Most of these are trivial with some IDE support and maybe a templating school, and probably not even an issue after your second week with Spring boot (or spring in general), and it's an improvement over what life used to be like but compare this with the general jist of how to do it in JS:
1. set up expressjs properly (usually a two-liner). It won't have things like @Cachable that spring boot provides to you out of the gate, but it generally has enough to get you up and serving requests.
2. Know what req/res are (the fact that calling res.send(...) sends stuff and .ends as well is arguably nontrivial) and how to use next
3. Know what a function is.
the code snippet I'm thinking of is:
It is "pretty much" the same, but how much work it is really depends on who you ask -- you can get up to speed with a simply built expressjs app in tens of minutes (many express apps follow a very simple setup pattern), but I've never seen that happen in a spring boot app for an absolutely fresh developer, even worse if the codebase is transitioning from spring to spring boot or has some other hacks in it.Spring Boot is marvelously simple one of it's best parts (it almost makes me want to use Java for a greenfield project), but there's so much noise in that code -- it should just be a function -- IMO all started with the decision in 1.1 (??) to choose Runnable over lambdas. Most of the complexity I'm ribbing Java over is just due to how you write the langage -- java on it's simplest day just can't be as simple as some of the stuff that came after it, since they had the benefit of hindsight.