Remember, Young Padawan: DRY
One of the software development principles that we get taught very early in our dev careers is DRY - Don’t ...
For further actions, you may consider blocking this person and/or reporting abuse
Hi Lili, sounds like you have been doing a lot of Vue / Nuxt / SSR stuff so you may be the right person to ask. I'd really appreciate your quick 2-second take on this.
I am thinking of creating a site like dev.to for a different focus area (a dynamic site with user-generated content, not a static site hosted on netlify). I love how snappy dev.to site is, every page loads so fast.
My back-end is currently in Laravel 5.8, and I don't intend to change that because I've spent the last 3 yrs learning Laravel. However, I am trying to get to a SSR or server-side-rendered app (as against the slow client-server default app). I care about speed (just like dev.to) and SEO is important also because of UGC. Which of these would you recommend if starting with Laravel and vue right now?
What tech stack / architecture would you use? Appreciate your thoughts!
Hi KP!
Our page is actually also UGC so I know exactly your thoughts / concerns!
Let me start by saying that apart having heard the name, I know VERY little about Laravel - but I do know it's often used with Vue, and I'm assuming the capabilities are roughly equivalent to any other backend-server, i.e. amongst other things, you can expose REST APIs out of it.
If that's the case, then we actually went through all 3 options with OSBO :)
We started with 1 - in our case, it was Java Spring Boot webapp, and Vue was embedded within just by importing from CDN, and later we also hosted the libraries from webapp. This I would only recommend for a very, very light touch website. You lose ability to package your app in a sensible way (it will be slower as you can't easily to code splitting, or otherwise use webpack), you start having messy code, and managing dependencies can be a nightmare. No helpful resources, as not many people do it this way. Overall, I'd strongly recommend against route 1. The familiarity of your existing stack will be tempting, but in the long run, it's a waste of time IMO (except, as said, with very light/static usage of Vue).
We moved on to 2, that is, a separate (plain) Vue app in Node.js server and Java backend with REST APIs. This is a huge improvement. The pros are that you are already in the land of "common standard", plenty of resources, cleaner code. The main con is that you now have to run two services. At the moment we run things on GCP and that means managing two deployments, two services (and paying for them) etc. But there are ways to cut the cost, if that's a main concern (it will be for us soon). Other cons are that you still have quite a bit of integrating tools on your hands (e.g. VueX, Vue Router, Vuetify - or whichever components framework you use) and, most importantly, SSR. You are right that SEO hints at using SSR, especially for sites that are not super-simple (google bots manage to process a bit of JavaScript - but you don't want them to process ALL of your content, it didn't work for us very well). You actually can do SSR with plain Vue, but in our case, that seemed so complex that this was exactly the point when we moved from route 2 to route 3.
Route 3 is, IMO, the absolutely best for complex Vue projects. It comes with an awful lot "out-of-the-box", and once you understand the SSR mode, it's actually really easy to work with. It takes some time, and I'm trying to write this up as I didn't find as many resources in this topic (apart from simple tutorials) as I'd like to - but... yeah. From what you said, your app seems quite similar in terms of architectural needs to ours, and Nuxt works really, really well for us.
Take a quick look at my guide to VueJS post - it's written from Java devs perspective, but I think the explanation of various Nuxt modes can be helpful for you regardless.
Any other questions, feel free to ask! :)
H Lili, phenomenal answer, thanks for taking the time to write this. It really helps (and I havent found a half-decent explanation anywhere). Even the Nuxt introductory video (why use Nuxt?) at nuxtjs.org/ is wayyy too complicated for a beginner to understand.
I did take a look at your post on the VueJs ecosystem: dev.to/lilianaziolek/a-super-quick... which is phenomenal in it's own right.
If I want to create a complex social networking app (ala dev.to or Linkedin), it sounds like "universal mode" is the way to go for me....is that correct?
Yes, Laravel is a back-end framework with powerful capabilities like APIs and lots of powerful features and integrations.
I really appreciate your perspective.
You're very welcome :)
Yes, IMVHO in Vue ecosystem, for any more complex applications, Nuxt in universal mode is the best thing since sliced bread ;)
As for your other questions:
Yes, in route 3 (and 2 really) they will both have their own little worlds. In our case, since we haven't grown too big yet, for now it is a single git repo, with subfolders for java/python/vue, and then further subfolders for projects. You could also create completely separate git repos - that is down to you, how big your team is (if any), and personal preference to some degree.
I don't think I came across any significant guide for this purpose - and since I just started blogging, I don't have our journey documented in any sensible manner. :( The good news is that, unless you have loads of code already (we had...) the migration should be relatively straightforward as it will be mostly moving files around (Nuxt requires you to put things in certain places) - but should not be a complete re-write.
Nuxt has a good "starter" project, so I'd recommend kicking it off from there, there is a route or two as an example.
One concept that, IIRC, is new to Nuxt vs plain Vue is the concept of pages vs components. Basically, pages are what gets automatically translated to Vue Router routes (if you used router already). Components, on the other hand, are the smaller building blocks. So whatever .vue files you now have, if it's mapped to Vue router route you'd move and name appropriately into /pages directory, and the rest would go into components.
Also, if you're using VueX, then there is a standardised structure for organising modules, and I'd recommend sticking to this instead of manually configuring VueX.
Finally, in our case the biggest stumbling block when decoupling from 1st way (all-in-one) was authentication/authorisation. I am a strong believer in backend driven security (i.e. "never trust the client") and I wanted to keep using Spring Security for this purpose. That was one of the most frustrating aspects of integrating the two technologies and I do have a blog post in plans for this, too. So, if you want a good (risky) place to start, I'd probably start from login and some basic authenticated user page. Once you have this working, all else will seem trivial in comparison ;)
Overall, if you have any specific questions (how to do X), feel free to shout. I have loads of posts in plans, but if I know there is interest in specific topic, I may prioritize it over some other less interesting/better covered topics.
Lili, I am so appreciative of your response! From both your posts and your detailed responses, one can tell that you have a ton of experience. Thank you for sharing your knowledge and expertise.
I just installed the nuxt starter project. I also found myself nodding my head silently in agreement to your points about:
I'm already following your updates. If you follow me back we can connect / message each other. Love to chat further and help you with OSBO if possible. I'm good on the business side.
Hmmmm, I just took a look at your laravel-nuxt project and the project structure looks quite a bit different than my typical nuxt project (see one linked from this post as example). Is this what was generated by
yarn create nuxt-app XXX?) I can't see any recent commits though so hopefully it's just because it's not pushed yet!Stay tuned, I'll put the auth post in line right after I finish this series.
Followed back, and happy to chat direct :) Would not mind if you have any hints on how to reach our target audience, haha! :)
Actually is the structure that different?
Compare the 'client' folder at github.com/cretueusebiu/laravel-nu...
with github.com/lilianaziolek/blog-exam...
Sounds good, look forward to reading more posts from you on this topic, and chatting 1:1 :)
Ah yes, client folder seems very similar. But it's inside of the other codebase, that's quite different. In my case spring boot app is in osbo/rest-api and nuxt is in osbo/nuxt - they are basically totally separate. That's what got me confused.
In this case, how would you typically build and deploy this to run? Do you just run two different scripts from the main folder, deploy two things and still end up with two separate services? Or does laravel end up hosting nuxt generated code?
Nuxt has "generate" option where you'd end up getting ready html/CSS/js to host, and if this code structure gives you that, and laravel then serves it, then it's not quite the same as option 3. And if you end up with two independent services, then whilst it can work from one folder, I'm not sure if I see the benefit of keeping it all in one project.
As said, I don't know much about laravel and how it's typically used with nuxt, so perhaps that's normal - but I just can't see a benefit of keeping these two protects blended into one if you're after the nuxt universal/two separate services route.
I can only speak to the development / local server, because that's all I have tested so far. Production might be more complicated, I'm not sure though.
To run this on my local / dev server, I basically need 2 commands, both run from the root laravel-nuxt/ folder:
php artisan serve ---> laravel starts listening on port 8000. Laravel development server started: 127.0.0.1:8000 and hosts the APIs in app/Http/Controllers: github.com/cretueusebiu/laravel-nu...
npm run dev --> this starts nuxt on localhost:3000.
You then go to localhost:3000 and it just works. Nuxt calls the Laravel APIs.
What do you think, given this description?
I'm not familiar with the nuxt "generate" option..so I am confused / curious what you think.
What is the benefit of the two separate services route?
Technically the 'client' folder could be external to the Laravel app (laravel-nuxt), and I have done exactly that in Laravel -> Vuejs SPA apps, but never with Nuxt. I just started with the codebase above. What is the drawback of having them all in one project?
ps. also left you a message
If you end up with two servers (Node.js running Nuxt/Vue on 3000 and Laravel server on 8000), then I think you are indeed on route 3 :)
Overall, you can keep it this way as it works, but there doesn't seem to be a requirement to keep it all in one folder. To a degree it's personal preference. I would/do keep things that run as separate processes and involve different tech in separate directories - just to make it easier for anybody looking into this code to see where the boundaries are (it also makes managing deployments easier for example). But, it's just a minor point, as long as you end up with these two servers running, all is fine and will work:)
Generate option: it's just an option in Nuxt to generate a static site. It will create a dist folder with everything (HTML/CSS/JS rather than .vue files) inside ready to be deployed.
That's good to know, Lili! I was worried that I was going down a wrong path! I agree with you, keeping the folders separate and managing the deployments separately makes a lot of sense. Right now, since it's just me and I don't have a team, I'm going to keep them all in one folder (though I may make the 'client' folder it's own git repo and the master repo include it as a git submodule: git-scm.com/book/en/v2/Git-Tools-S...)
One thing that is still confusing to me is why this repo has a router.js
github.com/cretueusebiu/laravel-nu...
I thought Nuxt automatically compiles the routes based on the files in the directory. Not sure if you have an idea what this is for...
Re: router.js - you are absolutely right, Nuxt will create router.js based on /pages folder structure (you can see this in sample project for this post too). Not sure why there is one in your source code... Maybe a leftover from another approach? Or maybe sth went wrong in code generation in Nuxt template? Either way, you should not need it, and I'm not sure what happens if you have it (will it override Nuxt, or just be ignored?).
Thanks Lili. Upon digging deeper this is what I found / filed: github.com/cretueusebiu/laravel-nu...
He is essentially overriding the default Nuxt functionality of auto-creating routes because he likes doing it the manual way. So yeah, I've asked him to remove it and he seems open to the idea.
Lili,
Great summary!
With Nuxt 2.12 (released in March 2020), the capabilities of the fetch method have changed (some would say improved), specifically the availability of
thisin the fetch method.I learned about it here: nuxtjs.org/blog/understanding-how-...). Might be a great excuse to revisit this list and update the post.
Thanks,
Ian
Hello Lili,
Recently I created Website using Nuxtjs, Everything is going fine after that i added dark mode in website and then the problem starting, I saved dark mode data in local storage and when i call it from default page it works but after some sec first show normal page and then it changed to dark mode.
Here is my code:
beforeMount() {
if (this.$ssrContext) return
this.$vuetify.theme.dark = localStorage.getItem('darkmode') === 'true'
},
After some time i know that beforeMount() is only working in client side that's why this happens.
I want to know what should i use to apply dark mode before render, In simple work i want to know alternative of beforeMount() in SSR
App Mode - Universal (Server Side Rendering)
Have you tried using cookie instead ?
You might find this helpful
github.com/microcipcip/cookie-univ...