I have a simple vue / nuxt project that I would like to serve from AWS lambda.
For this, I'd like to group everything into a single file.
I see that Nuxt is splitting the files in order to only load what matters at a given time, but the app is a single page, is for internal use and loading time / memory usage is completely irrelevant.
My question is 2 fold:
how can I disable the file splitting
is there a way to pack everything into a single index.html file? I didn't find a solution on the web because the moment I start to research solutions, I keep finding posts about SSR which is also totally irrelevant to my case.
For the split part, this one with all set to false should be enough: https://nuxtjs.org/docs/2.x/configuration-glossary/configuration-build#splitchunks
Like this
export default {
build: {
splitChunks: {
layouts: false,
pages: false,
commons: false
}
}
}
This one should also help: https://github.com/nuxt/nuxt.js/issues/2363
You also can have the whole control of the webpack config here: https://nuxtjs.org/docs/2.x/configuration-glossary/configuration-build#optimization
As for hosting on Lambda, you can check those 2 articles:
https://www.serverless.com/examples/aws-node-vue-nuxt-ssr
https://medium.com/#fernalvarez/serverless-side-rendering-with-aws-lambda-nuxtjs-b94d15782af5
Related
I'm using React 17 with cra-template-pwa to create a PWA. One of my UI libraries has several hundred static image resources that all get preloaded in the PWA (and I don't use most of them). This causes a long delay in enabling the PWA, and even causes Lighthouse to crash. I'm looking at various approaches to fixing the problem, but for a quick fix just to run lighthouse, I'd like to just disable precaching. I haven't been able to find concrete info how to do this. Any advice?
The cleanest solution would entail using the exclude option in the workbox-webpack-plugin configuration, but that requires ejecting in create-react-app.
Something you can do without ejecting, though, is to explicitly filter out entries from the injected self.__WB_MANIFEST array before passing the value to precacheAndRoute().
Your service-worker.js could look something like:
import {precacheAndRoute} from 'workbox-precaching';
// self.__WB_MANIFEST will be replaced with an
// Array<{url: string, revision: string}> during the build process.
// This will filter out all manifest entries with URLs ending in .jpg
// Adjust the criteria as needed.
const filteredManifest = self.__WB_MANIFEST.filter((entry) => {
return !entry.url.endsWith('.jpg');
});
precacheAndRoute(filteredManifest);
The downsides of this approach is that your service-worker.js file will be a bit larger than necessary (since it will include inline {url, revision} entries that aren't needed), and that you'll end up triggering the service worker update flow more than strictly necessary, if the contents of one of your images changes. Those unnecessary service worker updates won't actually harm anything or change the behavior of your web app, though.
I am coding a little website to be my homepage.
So far I managed to do what I wanted with express and handlebars templates but I am doing this website to test my boundaries, and I lack using a frontend framework and working with web components.
so for the sake of challenge and learning, I settled on svelte
which is not exactly a framework, I read, but is a delight to write with and seems very promising on the performance side.
The problem is I want to keep the hand on my website, and sapper, the full framework that comes with svelte, is a bit too much of a black box for me.
(you put this file here and that file there,
compile with this complex configuration you shouldn't touch
and BOOM you got routes)
What I would like is to use express to manage the routes and then render the svelte app, either with a different page/app for a route, or the same app with different variables.
Could anybody point me in the right direction?
I considered using sessions or a socket, but I have no idea of how to listen to this client-side and the documentation/articles about svelte are sparse and all talk about sapper.
here are a few lines of code I wrote in a test app. I know it's not the way you do it but it was for curiosity's sake
// --------------server.js
// ...
app.set('view engine', 'hbs')
app.set('views', path.join(__dirname, '../views'))
// Using a view engine on TOP of svelte
// is certainly a bad choice
app.use(express.static('app/public'))
// to make the svelte compiled .js and .css available
app.get('/test', (req, res) => {
res.render('home', {user:true})
// I tried to send props like this
// it did not get the props in svelte,
// but what I found is that svelte ADDS itself to the page
// and does not remove the HBS code, event though it is in the target container
})
edit
I will finally use sapper, thank you for the advices...
I really would like them to implement some sort of svelte middleware that allows to render/serve pages individually (once they are build of course)
If you do it like that, splitting your web application into several independent svelte apps that are served from express, then you need to keep the (web-)application wide state on the backend or keep it in the local storage on the browser. You can't use the states provided by sveltes store (writeable, etc), because that's in-memory and destroyed whenever you navigate to a new page (via express).
If sapper is to much magic but you want to keep running a single-page-app, have a look at svelte-spa-router. That isn't configuration based.
Just confirming a basic fact.
To run an introductory example
// Define a new component called button-counter
Vue.component('button-counter', {
data: function () {
return {
count: 0
}
},
template: '<button v-on:click="count++">You clicked me {{ count }} times.</button>'
})
the storage needed on my hard disk is of the order of 175MB.
Am I missing something, or is this the way it is with Vue.js v2?
I'm guessing with 175MB you mean a CLI and NPM based development environment.
Well, no, in order to run that introductory example you don't necessarily need such environment.
You can follow the <script>-based development environment, which will take little to none space, because Vue will be loaded from a CDN.
That said, you could hit the limitations soon after "deepening", like when starting with Single File Components. Also the big part of QA and tutorials assume CLI env.
Keep in mind that this is the workflow with any modern JavaScript framework's dev environment. That taken space is there for a reason, and it is to help you build your app, for example with Vue's CLI you get "hot-reload, lint-on-save, and production-ready builds" and more. Also you can add NPM packages and import them into your project
I would like perform some size optimization on generated files by qooxdoo. 800Ko is quite huge... For information, it is based on a desktop approach.
I'm using this configuration :
"OPTIMIZE" : ["basecalls", "comments", "privates", "strings", "variables", "variants", "whitespace"]
Without success...
Any idea ?
Client optimisation
It's the easy way. Set up gzip compression in your web-server. It'll make your build ~ 200-300 kB. You can even pre-compress your build and serve app.js.gz directly.
Then set up your web-server cache. On way is to configure reasonable cache expiration time, e.g. a week or a month. For more aggressive caching, expiration is set to forever (years) and your build URL looks like /static/app.js?v=123. You can use simple incrementing number, VCS revision or file hash.
Partial build
Harder but more flexible way is to use parts and combine it with client optimisation described above. This way you can build your application in the way that it loads its components on-demand and won't require loading everything upfront. This however requires changing your application, making in more modular and less coupled, which is generally something good though.
In your config.json you need to define parts, the components of your application that usually correspond to different functionality. I usually extent common job like this:
"common" :
{
"packages" :
{
"sizes" :
{
"min-package" : 64,
"min-package-unshared" : 16
},
"additional-merge-constraints" : true,
"parts" :
{
"boot" :
{
"include" : ["${QXTHEME}", "${APPLICATION}.Application"]
},
"functionality1" :
{
"include" : ["${APPLICATION}.controller.Functionality1"]
},
"functionality2" :
{
"include" : ["${APPLICATION}.controller.Functionality2"]
},
...
}
}
}
Boot part here contains minimal Qooxdoo dependencies required for bootstrapping the application. Note that unlikely your boot part will be less than 500 kB (uncompressed).
Then when you want to use some functionality you do:
qx.io.PartLoader.require(['functionality1'], function()
{
new (qx.Class.getByName('app.controller.Functionality1')).doSomething();
}, this);
Note that the part loader resolves dependencies for you, as part functionality1 may have its dependencies. In fact, partial build with 3 defined parts above may lead to less or more than 3 files in result. The generator uses sophisticated dependency management so it can split and collapse parts if it benefits the load performance.
The optimization config you are using is the default one. So you should already get an optimized build, when you run ./generate.py build. Look into build/script/{myNamespace}.js. The first part of the script (the managing or loading code so to speak) isn't optimized, but the framework code and your app code is optimized (one long line at the end, which is minified etc.).
The manual has more details:
How to configure the optimizations?
Which optimization does what?
I've been looking at using Aloha for a project but I'm completely stumped by the documentation. I'm trying to create a repository following the documentation and I have this so far:
requirejs.config({
paths: {
'jquery': "http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min",
'aloha': "http://cdn.aloha-editor.org/latest/lib/aloha",
},
});
define(
['jquery'],
function($) {
"use strict";
require(['aloha'], function(localAloha) {
console.debug(localAloha);
console.debug(Aloha.AbstractRepository);
});
return {};
}
);
Now. This tries to pull Aloha and jQuery from an appropriate CDN, and it works fine. However, despite what the Aloha documentation tells me, localAloha is not defined (it appears Aloha doesn't return itself) but that's not a problem since my that point it's in the global namespace anyway.
More frustrating when trying to define a repository is the fact that Aloha.AbstractRepository is undefined, despite all the examples, and code from live projects like the Drupal Aloha plugin, telling that all I need to do is extend Aloha.AbstractRepository.
Does anyone have any idea what's going on here? Aloha looks great, and is perfect for what I have in mind, but it's proven to be very difficult to actually get it working.
here is some code which should help you.
a php script is reading files from direcotries (eg. upload dir) and generates a json file with that information. that json is in the format which can be used by a js file (repository api) to tell aloha editor what's in your repository: http://ge.tt/1VJqium/v/0?c