For production environment, I can accept that golang can not hot swap. But for development mode, must I recompile whole project, and restart server, even just modify 1 line of code? Is there any way to quickly hot swap code to check result for debugging?
You use or create a watcher process that looks for changes, will recompile and restart the server when it identifies a change.
Here are some examples of this. I use Beego and bee rebuilds my server during development all the time.
Gin
GitHub: https://github.com/codegangsta/gin
gin is a simple command line utility for live-reloading Go web applications. Just run gin in your app directory and your web app will be served with gin as a proxy. gin will automatically recompile your code when it detects a change. Your app will be restarted the next time it receives an HTTP request.
Fresh
GitHub: https://github.com/pilu/fresh
Fresh will watch for file events, and every time you create/modify/delete a file it will build and restart the application. If go build returns an error, it will log it in the tmp folder.
Fresh works specifically with Traffic, Martini and gocraft/web.
Beego bee
The Beego web framework also does this. This is implemented in bee, a CLI tool for running Beego.
Website: https://beego.me/
Framework: https://github.com/astaxie/beego/
CLI App: https://github.com/beego/bee
bee will watch all the project directories by default and has an option to also watch the vendor directory.
Related
I'd like to create a simple web application to manage some data. The application will use PostgreSQL but I have no idea how to package everything in order to make it run on windows, linux, and mac. I can cross-compile a go binary which will include everything (web server, etc..) but the postgresql database will be left out because that's running as a separate server locally. I heard about docker but I don't know if that's the right solution.
Should I create a docker container and include PostgreSQL in it so I can start that web app on any platform?
You don't need Docker to do this.
It complicates things since your users will have to install the Docker engine first. Go is perfectly capable for cross platform applications, batteries included.
Decide if you want your app to run in a browser tab or should it have it's own window?
For a browser tab compile your app for the target architecture and think about a URL scheme that will make sense to your users, for example
localhost:8080/app => the user interface. This route is the web app, it serves HTML, JS and CSS. Tell your users to run the executable (or install it as a service, see this or use a platform specific tool like this one). Then open the link in a browser
localhost:8080/api => backend routes. Serves data to requests made by the user interface. For talking to the Postgres server running locally
If you want your app to run in it's own window have a look at Electron. See gotron: Go Api for Electron
If you want to use Docker for this, you have to create a platform-specific docker image containing the platform-specific binary in it. Once you have these images, you can use docker-compose to run your app with an instance of postgres running in its own container.
I have 2 repositories residing in Bitbucket - Backend (Laravel app as the API and entry point) and Frontend (Main application front-end - VueJs app). My goal is to set up continuous deployment so whenever something is pushed in either of the repos in master (or other branch selected by me) branch it triggers something so that the whole app builds and reaches the AWS EC2 server.
I have considered/tried the following:
AWS CodePipeline and/or CodeDeploy. This looked like a great option
since the servers are in AWS as well. However, there is no support
for Bitbucket out of the box, so it would have to go to Bitbucket
Pipeline -> AWS Lambda -> AWS S3 -> AWS CodePipeline/CodeDeploy ->
AWS EC2. This seems like a very lengthy journey and I am not sure if
that's a good practice whatsoever.
Using Laravel Forge to deploy the Laravel app, and add additional steps to build the VueJS app. This seemed like a very basic solution,
however, the build process seems to fail there as it just takes long
time and crashes with no errors (whereas I can run exact same process
on my local machine or a different server hosted elsewhere). I am not
sure if this is issue with the way server is provisioned, the way
Forge runs deployment script or the server is too weak to handle it.
The main question of mine would be what are the best pracises for deploying the app of such components? I have read many tutorials/articles about deploying a NodeJS app, or a Laravel app, but haven't gotten good information about a scenario like this.
Would it be better to build the front-end app locally and version control the built JS file? Or should I create a Pipeline in Bitbucket that would build the app and then deploy it? Or is it the best to just version control and deploy the source files and leave the whole build process as the last step in the deployment process that will be done by the server that is hosting the app itself? There are also some articles suggesting hosting the whole front-end app in S3 bucket - would that be bad practise as well?
Appreciate any help and resources that would help!
From the sounds of things it sounds like you have two types of deployments you might want to run.
Laravel API: If you're using Laravel Forge already then this is a great way to go about deploying your Laravel App, takes care of most of the process and easy server management.
Vue.js App: Few things you can do here, I personally prefer using a provider like Vercel or Netlify who let you deploy your static sites/frontends for free-low costs. You can write custom build steps but they have great presets that should work out the box.
If you really want to keep everything on AWS then look into how to host static sites on AWS
I have a Golang app running on Google Cloud App Engine that I can update manually with "gcloud app deploy" but I cannot figure out how to schedule automatic redeployments. I'm assuming I have to use cron.yaml, but then I'm confused about what url to use. Basically it's just a web app with one main index.html page with changing content, and I would like to schedule automatic redeployments... how do I have to go about that?
If you want to automatically re-deploy your app when the code changes, you need what's called CI/CD (Continuous integration/deployment). What a CI does is, for each new commit to your repository, check out the new code and run a test script. If all the tests pass (or if you don't have any tests at all), the CI server can then deploy your code to App Engine, all automatically.
One free (for open-source projects) CI provider is Travis CI. To configure it, you need to make an account with Travis, and a file called .travis.yml in the root of your repository. To set up App Engine deploys, you can follow this guide to set up a service account and add the encrypted file to your repo. It will run a gcloud app deploy from a container on their servers, whenever you push code to a certain branch (master by default) in your repo.
Another option, which avoids setting up CI at all, is to simply change your app to generate the dynamic parts of the page when it gets requested. Reading the documentation for html/template would point you in the right direction.
I have deployed a rails application in a server using capistrano. What is the best way to debug this app in production?
Until now, when I used Apache+Phusion to deploy apps, I would write debug statements in the code and determine what was breaking.
But when I try the same now in the capistrano setup, I don't see the debug statements.
Where should I add the debug statements? In the code base that is pulled from the git repo? Or the current folder of capistrano?
Also, once I add the debug statement, is there anything I need to do to nginx server to reflect this change?
(Earlier, in Apache+Phusion, I used to do touch tmp/restart.txt to reflect the change)
Sorry for these questions, but this is my first time using Capistrano, Nginx.
I was deploying another agent's code, hence I wasn't fully aware of the deployment environment. On probing, I found out that the app server being used was Unicorn.
So, all I had to do to reflect the changes was restart Unicorn server by running unicorn appname restart
I have moved parse sever from parse.com to heroku. Everything is working fine except cloud code('cloud/main.js' file).
I have replaced "main.js" of parse.com with "main.js" of parse server code and deployed on heroku, but it is not working. Getting following error when I make request from my mobile app
{"code":1,"message":"Internal server error."} (Code: 1, Version: x.xx.x)
Any idea?
Note:
I've followed following link for migrating parse server
https://learnappmaking.com/how-to-migrate-parse-app-parse-server-heroku-mongolab/
Migrating cloud code can range in difficulty depending on how involved that code is. Here's a workflow for validating your code:
1) Check that you can build your Heroku app locally with the right Node version.
2) Comment out all of your cloud code. You want to start introducing your code in parts and make sure it compiles with each re-introduced function.
3) Install the node modules for each service that you use. If you use stripe/mailgun or any other package, add them in your package.json file and run npm install. Then include them in your main.js file with the require('packageName').
4) The cloud server uses Express.js version 4.2 and a Parse.com runs Express version 2.0 or 3.0 but not 4.0. If you use any middlewear then you need to change it to the proper Express 4.0 syntax/methodology.
5) There is no support for cloud jobs so rename all your *.job functions to *.define and comment properly so you can come back to them later. If you did not use cloud jobs then don't worry.
6) If you did use cloud jobs, now you need to setup a heroku worker/scheduler to run those old *.job (now *.define) calls at the proper time intervals you had.