This forum has moved, please join us on github discussions. We will keep these old posts available for reference. Thank you!

Seeking advice to speed up server restarts

Works in Progress
#1

Hi All!

I am working on my first big project with Apostrophe and I am following the tutorials and documentation as I go. I dig what I’ve been seeing. The one thing that keeps me from feeling productive is how slow it is to reboot Apostrophe.

Whenever I make a change to a template or some LESS, I need to reboot the whole server to see the change and this it takes about 30 seconds each and every time. I know about the nodemon module, and have used it, but it still feels like it takes way too long for me to see a change in my code appear in a browser.

Maybe I am missing something fundamental here, but this part of the dev experience is rather bothersome.

I have taken to designing what I can elsewhere using quicker tools then converting them to into the Apostrophe templates required, but this feels a bit wrong somehow, plus once I get things wired up I still have to debug and every change still takes about 30 seconds.

What is your workflow when developing sites using Apostrophe? Does everybody just deal with the compile time? Is my machine to blame? Am I just being impatient?

#2

This is one reason, I personally, am a big fan of decoupling the Front-End Public facing application from the CMS. I know that Apostrophe is working a lot on the performance of their applications in regard to Front-End, but it’s not there yet. When I first started using Apostrophe I was using Chrome’s dev tools to write my css and then porting if over in big batches before testing. It was kind of a pain, but did save on restarts. In the end, though, I took advantage of using Apostrophe as a service with the headless plugin. It freed me up to use any front-end frame work I wanted to. If you’re dealing with a site that is design-heavy, it might be something that you should consider. That said, I am very excited about what Apostrophe offers and where it’s going and do believe that it’s the best open source Node/Mongo CMS solution to date.

1 Like
#3

30 seconds is a long time. For comparison purposes, what computer are you seeing that behavior on?

It takes about 3-4 seconds for me, which meets my personal standard of “basically no time,” but I’m on an i7 Mac.

Unfortunately we probably can’t speed up the actual restart of Apostrophe because the vast majority of that time is spent in the require function of Node.js. But, it’s possible we could detect frontend changes better and account for them without full restarts at some point.

1 Like
#4

Knowing that you were driven by the restarts issue to switch to a separate frontend application is certainly motivating. (:

1 Like
#5

it’s possible we could detect frontend changes better and account for them without full restarts at some point.

This would be my recommendation!

1 Like
#6

Yeah, I am running on a sad late 2008 Macbook Pro with a dinky little Core 2 Duo. Surprisingly I have been able to develop things pretty well till now.

I’ll look into using Apostrophe-Headless, but one of my favorite parts of Apostrophe is the in-context editing. My client was very pleased when I pitched them that feature. I figure that does not carry over if you remove all the front-end glitz and glamor that Apostrophe gives you, am I wrong?

#7

That’s correct, it does not carry over.

I think it would be valuable to zero in on what types of automatic, restart-free reloading are most important to developers. I would guess those are:

  • Styles. We already have this in dev for LESS styles. If you are using something else to build your styles you can set up its own auto-rebuilding and as long as it updates the output file you’re pushing to Apostrophe… ditto.
  • Templates. Most templates hot-reload in Apostrophe, but not all.
  • … What else is there? Code, of course, but it is in the nature of node to restart when code changes.
#8

Blaine, a question I would ask is whether you’ve looked at adding React and/or Vue apps to your pages powered by Apostrophe’s frontend. We do this a lot and we haven’t really had problems. But it could be that you want to avoid any real page transitions at all, which would take some new plumbing as users navigate from one Apostrophe “page” to the next.

#9

I’m also curious if you have looked at apostrophe-lean-frontend, which removes all the frontend js libraries we normally push to logged-out users. That might remove some of the burden you see in using Apostrophe to render pages, depending on what your concerns are.

#10

I would like to see some examples of that. My main concerns were performance. Server-side data requests and rendering, code splitting, and utilizing prefetching and preloading. I then started building a component library that contains many smaller styled components that combine to make larger components that have corresponding apostrophe modules. My component library is growing and I will be using it for both static and dynamic sites. But if there is a clean React front-end that can tap directly into the apostrophe data without making an API request, I’d be very intrigued.

#11

So you’re doing pure “single-page” apps, OK.

Apostrophe is mostly focused still on situations where the user might just be interested in this page, or perhaps three or four, and there isn’t a ton of interactive javascript per frontend page. In that situation it doesn’t necessarily make sense to pay the startup costs of a frontend framework in the browser.

There has certainly been discussion of a “pure Vue” approach for a future release, in which sites would be developed entirely in a frontend framework. But so far the consensus of the developers we’ve talked to is that they are not ready to give up Nunjucks templates and fast server side rendering entirely; they still really want web pages, with the occasional frontend javascript app sprinkled in where appropriate.

#12

I wouldn’t call it a pure SPA. Not to play devil’s advocate, but with server-side rendering, isomorphic routing, compression and code splitting, you’d be surprised how little the load is. Check out the network panel ( filtered by js ) on this site: http://godfreydadich.com/ You’ll see that the first 4 js files ( loaded before doc ready ) are pretty small. The rest are loaded after the page is ready as a preload for future clicks. Clicking around in the site after that ( with the network panel open ) is pretty impressive. But I don’t want to be prattling on, if you already know this stuff.

#13

Oh no, your input is welcome. We’ve had some partners complain of performance issues on the server side caused by SSR, and we’re hearing that Vue/React may be inherently slower than Nunjucks as far as rendering a page goes, but we’re interested in evidence to the contrary.

#14

I think Next.js and Nuxt.js are crucial for optimizing isomorphic/server rendered JS for React and Vue respectively. I’d be curious to see server performance measurements before and after a Vue/React used Nuxt/Next then also put against Nunjucks. Sounds like an interesting experiment to me. Also, depends on how the code is written ¯_(ツ)_/¯

#15

Hey, check it out: we have a new module that addresses your concern about slow restarts.

Apostrophe now has its own nodemon equivalent, but optimized for much faster restarts of Apostrophe. This is going to be a huge help to folks on less powerful laptops. A fast Mac can start Apostrophe quickly, but you really feel the chug of all those require calls on anything less, especially if you don’t have an SSD. And we can do other clever things with this over time.

This tool takes advantage of the fact that Apostrophe can be shut down and started up gracefully… and that we can tell “npm” to forget about specific files so they can be required again, without starting from scratch.

This is in beta, I’m hoping to get feedback before we npm publish:

Looking forward to your input!

2 Likes