Feedback (pros, cons, comments)

[tipsy]

No description provided.

[rgmz]

Cons
...
No transpiling (can’t use the latest JS features without code breaking in old browsers)

I wonder if you could use the maven-frontend-plugin (or something similar) to do this.

[tipsy]

I'm not sure. Since the JavaScript isn't exported as modules, I imagine it will have some trouble 🤔

[stepbeekio]

This looks terrific! I'm a part of a small team of full-stack devs. We love Vue.js on the front end and a JVM stack on the back-end. We've been feeling pain for a while in having this split across two systems. We've been looking into Java template engines (last experience was with jsps and Thymeleaf) but this could well be a winner!

In the article you still use a JSON API to fetch data for the render. Can I ask why? It seems like rendering with javalin shared data would work fine. Have you tried this for data other than auth and run into trouble?

[tipsy]

It's would work fine, but most of the apps I have are dynamic and will update data when you add/edit/delete. It's simpler to just have 1 way of loading data.

By the way, since I wrote this article I have started using the approach on two large projects at work without issue. It's making us very productive :)

[cwildfoerster]

Im testing this approach now too for our next applications based on micro services. Im in my early testing phase, but its looking good for now. I will keep you updated. Thank you very much @tipsy

[tipsy]

Nice! Looking forward to see how it works for you.

[cwildfoerster]

I just. experimented with the vue-router, doesn't require much work... but if you want to get the state... thats another issue ;-) I guess i will push the router approach a little further back

[tipsy]

For me the best part about the server side routing is that it renders the correct component on load, and that access management works the same as for the API.

[cwildfoerster]

Yes, thats what i noticed too that i would have to duplicate the access restriction. What do you think about only including views into the componentRegistration that the user has access to, according to the access manager?

[tipsy]

I don't think that's required, the HTML itself shouldn't be sensitive. It would reduce the payload though, which is good 🤔

[unaor]

I have a fairly big angular project (100 components) that im planning on doing a rewrite, i really like what i saw on the tutorial. in your opinion is it suitable to use the approach for a big project?

[tipsy]

What browsers do you have to support?

[unaor]

currently all the way down to IE8 but im trying to see whether it will be just chrome, firefox and edge

[tipsy]

Yeah, this would be a bad idea for IE8, but it works really well for modern browsers.
100 components sounds fine, I guess it depends a bit on how big they are. My current project has 49 components, which results in a payload of 29kb (in other words, not an issue).

[vlaate]

Thank you for writing this @tipsy, it has been a most enlightening read. Not only did you save me quite a bit of time, but convinced me Javalin deserves more than the cursory look I had given it.

After all these years it still impresses me how small libraries with just the right choices can often provide more value than huge behemoths. Thank you!

[tipsy]

I'm glad you like it! I guess Javalin is the result of doing "just enough" for a lot of years. It's gained some weight lately with the extra modules, but they very much optional :)

[1fexd]

Hello, is there a reason all .vue templates are always sent to the client (even login protected ones)? Isn't that kind of counter-productive?

[tipsy]

@gringofe If the templates were split based on roles it wouldn't be possible to cache the bundle anymore (you would have to rebuild everything for every request). Sensitive data shouldn't be put into static HTML/JavaScript files, you would have the same issue if you put sensitive data in your app.js in a "normal" JavaScript app.

It might be counter-intuitive though, we could include it as a config option?

[1fexd]

I don't think creating a config is necessary, I was just wondering if it's normal for all the files to be sent, since I am not doing a lot of frontend webdevelopment. btw, thank you for creating Javalin, it has been a pleasure working with it so far.

[tipsy]

I was just wondering if it's normal for all the files to be sent, since I am not doing a lot of frontend webdevelopment. btw, thank you for creating Javalin, it has been a pleasure working with it so far.

Happy to hear it!

[tipsy]

... for unit testing a web pack config could be created and you just run it as a separate process.

I'd be very interested to hear more about this if you manage to set it up.

[lwhite1]

Hi, Thank you for this. I love the approach.

It's probably my lack of understanding how webjars work, but I have been unable to get it to work with any Vue or Vuetify components. For a simple example, in layout.html, I substitute

    <v-main id="main-vue" v-cloak> @routeComponent <v-main> 

for

    <main id="main-vue" v-cloak> @routeComponent <main> 

and get a javascript exception:

Cannot read property "bar" of undefined
Found in
---->

If I leave layout.html alone, I get similar errors trying to use any other Vue or Vuetify component in the template hierarchy. It would be great if the example went a little deeper and showed the use of Vue components rather than just HTML markup like

[tipsy]

Hi @lwhite1, glad you like it!

There really isn't more to it than what is shown in the docs/example. Once you add a WebJar to your project you need to rebuild (using Maven/Gradle/your-tool-of-choice), then you need to include the static files from these WebJars in your <head> (you can include them other places too, but using <head> makes everything easier.

You can look at https://github.com/tipsy/kotlin-admin-template for a more complete example.

[lwhite1]

Yes, you're right. It works ok, except that Vuetify doesn't see the icons and fonts it needs. Since it's material design, it's looking for Google's Roboto font and Google icons. The vuetify webjar doesn't seem to recognize them when they're brought in as standard links, or as webjars. I will see if I can follow the kotlin template code, (i'm using java) since that looks a little different. In any case, it's not a Javelin issue.

[tipsy]

You probably just have to find the correct version if the mdi font. I can find it for you tomorrow!

[lwhite1]

Got it using your template example. All set. Thanks much

…

On Sat, Jan 9, 2021 at 11:05 PM David ***@***.***> wrote: You probably just have to find the correct version if the mdi font. I can find it for you tomorrow! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA2FPASMYALRLFHB3ZDMHN3SZERQBANCNFSM4IIJPAHA> .

[TareqK]

Since im going to be adding some stuff about Vue3, i'd also like to put it forward that there is some kind of reloading for vue files now, just not for routes, so maybe put that as a pro now since its been fixed?

[tipsy]

How does the reloading work? 🤔

[TareqK]

Basically, if you use the rootDirectory in EXTERNAL mode, and Javalin is running in Dev mode(ie, requests from localhost or through a custom env variable), it always re-scans the files each request, kind of like it does in unit tests. I Use this often when developing apps(and since I usually dockerize, its no sweat off my back). I even do the same for static files(non-webjar), since i dont use inline files often and rely on those for style. Actually, when working purely on the front end, the only time i need to rebuild and run the server is when I add a web jar, and otherwise, i just refresh the page. I can add this to the docs, might make sense to throw this in the bottom around the "tips and tricks" section.

[tipsy]

The plugin has always supported that (I would die without it 😅), but hot-reload refers to updating the app without refreshing the page (so you won't have to recreate your state).

I will create a much richer docs page for the JavalinVue plugin soon, I will include that tip there :)

[SilverioMG]

Hi tipsy.
Thanks for Javelin Vue !!! It's incredible, I had been thinking about doing frontend in this way for a long time.

I have been practicing with your examples but I have a question with Authentication:

Once the user is authenticated, when storing the credentials (basic auth, token ...) I have only found 2 options:

1.- Save in the user's session on the server.
With this option the backend is not stateless and complicates horizontal scaling.

2.-Save a cookie and collect them on the server for each request.
This option is not advisable for security reasons.

My idea was to be able to send the credentials from the frontend to the backend in each http request as it is done in a normal web spa.
This can be done for Http requests against the rest api but when navigating to a vue view when a link is clicked, you cannot send headers in the view request.

Is there any other option?

Thanks greetings.

[tipsy]

Hello, and thank you @SilverioMG!

1.- Save in the user's session on the server.
With this option the backend is not stateless and complicates horizontal scaling.

I agree that it complicates things slightly, but Jetty has a pretty robust session handling setup. You can read more here: https://javalin.io/tutorials/jetty-session-handling

Going for this approach will also enable you to store other things in a server side session, which is quite nice.

2.-Save a cookie and collect them on the server for each request.
This option is not advisable for security reasons.

What security reasons? As far as I know, cookies are considered secure. This question on SO has some discussion on it: https://stackoverflow.com/questions/26340275/where-to-save-a-jwt-in-a-browser-based-application-and-how-to-use-it/40376819

This in particular seems like good advice:

HttpOnly
Secure
SameSite: Lax or Strict

Is there any other option?

The methods above are considered standard and secure, afaik. How are you handling your credentials currently, and why do you consider it more secure than the alternatives?

[SilverioMG]

Hi @tipsy, thanks for your answer.

Didn't know the 'sameSite' property of cookies.

I have tried to simulate the operation of the Authentication like in a web SPA (Angular 2>, React ...).
Trying that the user's credentials only exist in the memory of the browser while the javascript code is executing.

For this I use JWT and send the authenticated user info from the frontend to the backen and vice versa in each request.

For requests against the rest api I send the jwt in the 'Authorization' header.
For requests to navigate to a view/page I send it as query param in the url (I don't like this option very much).
In the case of wanting more security, I would add https.

If you want to see the code:
JavalinVue-Spa-Authentication

Sorry because the comments are in Spanish :)

After doing this mini project, now I think the simplest option would be to use cookies XD

Regards.

[ptomli]

FYI, the link to the POM from the tutorial is no longer valid, since the Vue2/Vue3 split
https://github.com/tipsy/javalinvue-example/blob/master/pom.xml

[tipsy]

Thanks @ptomli, I'll have a look.
Edit: Fixed!

[ptomli]

You mention in the tutorial that

Every VueComponent can take a state object as a second parameter. This state overwrites the state from stateFunction.

I had assumed that this would mean an individual key in the local state would overwrite an individual key in the global JavalinVue.stateFunction result, but it seems this is an either/or situation. Would it not make sense to follow a similar pattern to that used with JavalinRenderer.baseModelFunction, whereby state defined by individual handlers is merged with the global/base state?

I see the place where this happens is fairly simple, getState(ctx: Context, state: Any?) simply does mapOf(..., "state" to (state ?: stateFunction(ctx))). Whereas JavalinRenderer uses baseModelFunction(ctx) + model.

Perhaps a breaking change though

[tipsy]

@ptomli I agree, but when I brought this up for discussion everyone (to be fair, only like 3 people) said they preferred either/or.

It does help make the code more explicit, and it encourages you to pass state to all your components manually. You could pass baseModel(ctx) + model in your own code.

[torian257x]

I feel like you are implementing a variation of inertia js

quick example to inertiajs: at this time frame he is getting a bit to the point

https://youtu.be/XEW2d2XHkAk?t=2493

he already mentioned routing afaik, e.g. inertiajs uses server side routing as well.

wouldnt it be great having you integrate with inertia js as well? I certainly think it would be.

As well:
compilation is a pain in the a** yes, but that is why you use laravel mix. They have a standalone version as well.

https://laravel-mix.com/docs/6.0/installation#step-3-define-your-compilation
notice compilation is 2 lines

you can still access deeper compilation details, if you want. E.g. configuration etc.
But typically I build my scss and js there, maybe add babel whatever. But its fairly pain free.

I built reactjs with typescript support (for compilation, no typescript at runtime) as well using mix. Even though it usually requires some package or so.

[tipsy]

Thanks for your comment @torian257x! It definitely looks similar to inertia, but how would it integrate with it? It looks more like an alternative, as far as I can see 🤔

[torian257x]

you'd probably need to talk to the inertiajs people. Like how to tailor the minimum together to have something that works.

They actually created their own repos for laravel https://github.com/inertiajs/inertia-laravel and ruby
but its not very trivial to read through that, and if you dont know laravel, its straight up impossible I guess.

[TareqK]

@tipsy If I understand what they are doing correctly, its just a matter of adding the Handler(and plugin). Though im not sure what the value add is in our case; its an extra 4 lines of code/page to connect the API endpoint with the VueComponent. But its great that people are catching on to and thinking more about Server Side Routing anyway.

[tipsy]

For Javalin 5 we want to include a "plugin store" on the main webpage:

If you have used JavalinVue, it would be great if you could go to the rating issue and react/review: javalin/website#132