How can i set up server side rendered pages with Cloudflare Workers ? What frameworks support CF Workers in that sense ?
Long story short: you can use Nuxt3 with the cloudflare Nitro preset.
Here i will higligth a simple course of action thinking even in folks that never used Nuxt before.
Check out the Nuxt3 getting started
Create a project
Learn how to setup Nitro (the underliyng engine) to export a serverside renderer cloudfare worker
Deploy using Wrangler cli as described in the above article
Optionally but higly recomended (to even watch this first) see this short but enligthing talk about how all of this works
Related
Context:
I'm building a recipe website with Angular frontend and Node.js express backend.
I'm using Heroku for the backend and trying to use Firebase for the frontend. The backend is not ready for use, and is unstable. The frontend is almost ready for v1. For now, all I have is the ability to retrieve a list of recipes from the GET /api/recipes endpoint, and display them (and search through the loaded recipes). Eventually, I plan to add the ability to add/edit/delete/search through the recipes, as well as other endpoints. For now, it works equally well with a static .json file or a dynamic GET endpoint.
In the process of adding this to the backend, the backend will naturally go down and may become temporarily unusable at times, so I'm of course going to have two deployments of the API, and two deployments of the frontend. Prod and Dev, Live and Preview. This should be easy with Heroku, but Firebase is giving me some problems.
I want to have different configs for different deployments. A way for the front-end to ask Firebase "Where's the API I'm supposed to use". This shouldn't go in the repository, code once deploy many, yada: https://12factor.net/codebase . But I haven't figured out how to do this with Firebase.
Goal:
Firebase Remote Config should use a condition such as App Channel to send a different api_url parameter based on what channel the deployment is. This should not be stored in the repository. It should not give away the other deployments etc.
Whatever config I use should be build-once deploy-many. I do not wish to pass a config parameter such as configs:{"recipes.web.app":{apiUrl:"..."}, "recipes-preview-1239j20.web.app":{apiUrl:"..."}}. The frontend must not be aware of other deployments. It shouldn't even really have to be aware of where it's being hosted.
Current Progress:
I successfully deployed different versions to the live channel and the preview channel. I successfully made a RemoteConfig config using GUI (https://console.firebase.google.com/project/<project_name>/config). I did see how to add conditions. I successfully accessed RemoteConfig inside my custom service in Angular. I did find out that init.json on the preview and live channels are identical. I did successfully limit it to "If it's the recipe app", but it's useless because everything's the recipe app. There is a way to make multiple sites, but that's not really useful either, because I'd have to set up the entire app again.
I did not manage to figure out how to deploy remoteconfig.template.json from command line. I did not manage to figure out what conditions are useful. I did not manage to get the "Version" condition to be enabled in the condition selector. I did not manage to find any condition about "channels". I did not manage to find anything with "remote config" and "channels" even on the same page! I did not manage to find anything in firebase docs about "deployments".
Alternative and Unrelated Sidenote:
I'm extremely frustrated with Firebase, and if I can't figure this out, I'm going to abandon it in favor of a Heroku thing I just found. An "unsupported" buildpack for nginx (https://elements.heroku.com/buildpacks/heroku/heroku-buildpack-nginx). "Unsupported" as in it's unofficial. I'm familiar with nginx, and using that will make everything about this personal project (except the server location and build/deploy process) match up with what I'm doing at work. And also both halves of my personal project (static web and api) will be on the same host, which might make things nice.
I need Meteor App in production, without worrying about scaling in the future. App will have 500 user online in any one time - as maximum. I read in the oficial guide that the best practice for many reasons is deploy to Galaxy.
But there are also many articles about deploy to Digital Ocean and Heroku.
So what variant is the best?
Use digitalocean.
Set up nameservers, set up node on your droplet and have Mupx do the deploying. It's very easy and DO is cheap.
DO has easy to follow tutorials to do the initial setup and you will thank me later + your wallet will be happy.
I have used Galaxy in a production level app for one of our clients and it works fantastic. If you want a deployment where you don't have to worry about scaling at all, then Galaxy is for you.
With time, as your users increase and you find yourself needing more resources, you can assign better containers and CPU power with just the click of one button. It also provides complete logs and some performance metrics to help you in a completely meteor-specific manner.
The deployment process itself is as simple as having a settings json file, and running a one line command like:
DEPLOY_HOSTNAME=galaxy.meteor.com meteor deploy appname.meteorapp.com --settings settings.json
As we all know, we can run a meteor app by just typing meteor in a terminal.
By default it will start a server and use port 3000.
So why do I need to deploy it using MUP etc.
I can configure it to use port 80 or use nginx to route to port 80 for the app. So the port is not the point.
Edit:
Assume meteor is running on a VPS or cloud server with public IP address, not a personal computer.
MUP does a few extra things you can do yourself:
it 'bundles' the code into a single file, using meteor build bundle
the javascript is one file, and css another; it's minified, and obfuscated so it's smaller and faster to load, and less easy to decipher on the client.
some packages are also meant to be removed when running in production. For example meteorToys, the utility toolset to look up collections and much more, is not bundled into the production bundle, as per the instructions in its package. This insures you don't deploy code with security vulnerabilities (Meteor toys basically opens up client side delete / updates etc... if you're not careful)
So, in short, it installs a minimal version of your site, making sure that what's meant for development only doesn't get push to a production environment.
EDIT: On other reason to do this, is that you don't need all the Meteor build tools on your production server; that can add up to a lot of stuff, especially if you keep caches going for a while...
I believe it also takes care of hooking up to a remote MongoDB Instance (at least it used to be the case on the free meteor site) which is more scalable and fault tolerant than running on the same instance as the web server, as well as provision storage etc... if needed.
basically, to deploy a Meteor app yourself manually, you need to:
on your dev box:
meteor build bundle your app to a tar file (using the architecture flag corresponding to the OS you will use)
on the server:
install node v0.10 (or whatever is the current version of node required by Meteor)
you might have to install Fiber#1.0.5 (but I believe this is now part of meteor install already)
untar the bundle, get into bundle/programs/server/ and run npm install
run the server with node main.js in the bundle folder.
The purpose of deploying an application is that you are situating your project on hardware outside of your local machine. For example if you deploy an application on Heroku app you create a repository on heroku's systems and that code based is used to serve your application off of their servers.
If you just start an application on your personal system, you will suffer a lack of network and resource availability as well as under use of computer time at non-peak hours as your system will need to remain attentive for additional users without having alternative tasks. Hosting providers provide resources as needed, and their diverse client base allows their systems to work around the clock on a global scale.
I've installed AI, included in project (VS2013 Update4), but some of the metrics (app heath & diagnostics) are not working.
If i click "Learn how to", the help is always the same... I folowed all the steps, that must be done, but it doesn't work.
What else do I need to do, to get all of the metrics work?
see attached image:
http://i57.tinypic.com/nv75sz.png
thx
peter
confirmed that if you deployed your app to an azure website that you will miss seeing some data in the Application Insights blade. the 2 data flows that won't work specifically include 1) the runtime instrumentation agent - this acts like a profiler and automatically discovers your code dependencies like calls to SQL, another HTTP endpoint, Azure storage account or azure blob and 2) Windows systems performance counters.
1) is something that is very close to being released as an Azure website extension http://www.siteextensions.net/ and will depend on the .12 Application Insight SDK (not released yet)
2) is something that we are still working on an ETA for
Other data visible in the application insights blade should already be working on an azure website. If you don't see your data make sure you are looking at the right application insights resource and double check the instrumentation key. Also make sure you have manually added the client side instrumentation script which isn't added by default when we add application insights to an existing project (ie. not a new project).
What is best approach to have live code changes deployed to PROD.
So that
i don't have to restart my servers.
And don't want to push the entire bundle.tgz file
What are the options ??
We have a Meteor app in production - We upload the new bundle and prepare it (updating the native fibers) and restart - you have to restart the node thread.
You might say that you kick all clients, but Meteor is build to handle poor connections and will reconnect - it uses delay algorithm to help flatten out reconnects.
If the client is ready for migration the new code is then pushed.
Our app is running Meteor inside cordova and we use appcache making sure that clients can allways open our app even if offline.
NOTE: MDG is working on Galaxy - a cool and easy way of managing your own Meteor servers - so deployment would be a single line in a terminal. (eta aprox. first part of 2014)
Easy deployment to your own server (DigitalOcean, Amazon EC2, etc) can be done using meteoric.
Meteoric can setup your server and deploy latest commit to production.
I use it and it works great.