I see here: https://docs.expo.dev/build-reference/local-builds/ that in order to build my expo app on my own infrastructure, I need to have expo
Company policies that restrict the use of third-party CI/CD services. With local builds, the entire process runs on your infrastructure and the only communication with EAS servers is:
to make sure project #account/slug exists
if you are using managed credentials to download them.
Debugging (more info in the next section)
Is there a way to build my apps (iOS and Android) without having to be logged in to Expo servers in any way?
Related
I currently have a React-only app deployed on Hostgator (I used npm run build then just uploaded the files to cPanel) because it is just a front-end landing page. However, I am planning to add things like logging in and a user dashboard, which will "require" me to use Node.js, Express and MongoDB Atlas.
In this scenario, will it still be possible to deploy the website onto shared hosting on cPanel? It seems to me, from looking online, that this is not possible. In this case, what are my options for other hosting to deploy a MERN stack app on, and what are my options for backend hosting on cPanel that are not Node.js-Express-MongoDB? Do they have their own backend services?
Thank you!
I had the same query and the only solution that I could find was that it is not possible to deploy your MERN app on shared hosting and you need a dedicated server for your applications.
The best and cheaper way to do this is, wrap your application inside a container using Docker and deploy the docker image on a VPS (Virtual Private Server).
Or,
You can also use a separate service for everything that you have to configure yourself and then deploy your app. Kubernetes is the best tool to manage distributed systems.
I hope this helped you.
I developed a NuxtJS project locally and am trying to figure out how to deploy my project to a shared hosting provider list Host Gator.
I want to use the server side rendering functionality of NuxtJS so I will need to run
npm run build
But once I do that I'm not sure the correct steps to then deploy that built project to shared hosting?
As #AlexanderStaroselsky says, you will not be able to deploy successfully to shared hosting although it isn't because you can't run node, you probably can, it is because you can't run a reverse proxy once you deploy. I once foolishly tried to deploy a nuxt app to Godaddy shared hosting and it was a total nightmare.
I gained shell access and installed node and transferred all the files and ran npm run build and then npm start. All of this went fine and then was confronted with the issue of how to direct traffic to the nuxt app. On shared hosting you use a .htaccess file to direct to index.php or index.html but you need to make the rewrite rule to direct to http://localhost:3000 which you can put into your rewrite rule but it seems to block the correct functioning of the app. I was able to get the app visible but it didn't have any functionality. The routing didn't work, any images sourced through require('~/assets/images/...') didn't display and it was totally unworkable.
What you need is to be able to install nginx to set a reverse proxy and shared hosting never offers root privileges for you to be able to install it. What you need is a cloud hosting provider which gives you a virtual server with full root privileges to install nginx, node, and any other packages you might want. There are plenty of them out there that are affordable (probably more so than shared hosting) and easy to use, such as digitalocean, aws, google cloud, upcloud and so forth.
There can be a bit involved in deploying a nuxt app especially if you are using a rest api and then more so if you wish to add an ssl certificate but there is documentation out there to do it.
All that said, if by some miracle you ever find a way to successfully deploy to shared hosting let me know and I can dust off my godaddy account that I stupidly paid for several years worth of and don't use.
I am not sure if this is a thing, or possibly and issue. I am hoping others have experienced it. But every time I put a dev build on my iphone through xcode, the app works fine on the device while unplugged from the computer for about a week. Then the app crashes at the splash screen. Every dev build of an app I have loaded on my device has done this. Even example apps I have downloaded from the web.
Does a development build of the app expire, or maybe the certificates expire or some other issue that causes the app on the device to start crashing after its been on the device for a certain time?
Solution 1: Turn off the WiFi on your iPhone or just make sure your phone and your PC are not on the same WiFi Network.
Solution 2: Run your app on the device using a Static Js bundle. To build static bundle follow these instructions for running on device via static bundle
Reason: This happens because when your phone and PC are on the same WiFi network then the app on phone tries to connect to the app development server to load the latest Js bundle, but when it could not connect to development server or could not fetch the latest Js bundle then the app crashes. By turning off your WiFi or changing the Wifi network causes the application to load the pre-build bundle and prevents the app from crashing.
I ran into the same thing and finally figured it out. If you're using a Xcode provisioning profile instead of signing up for the Apple Developer Program and paying yearly then what you're doing is getting a temporary profile that lasts about a week. Once it expires, any device with the app installed will stop working until you rebuild it with the new profile. You can see your profile/expiration if you go to General->Signing and click the 'i' next to provisioning profile.
I hope If app is opening to splash screen then there is no wrong with application building. After Splash are you going to use any web services or related to your localhost site. If yes then definitely issue is there.
Let me know if it is helpful .
When build on your phone, you want to change your scheme to Release. Please follow this https://facebook.github.io/react-native/docs/running-on-device.html, which will show you how to change your scheme to Release.
If you did lots of upgrade when developing, you might want to delete the node_modules folder, and do a clean npm install again, prior to build on phone process.
I have a React + Webpack/Babel + Node/Express application and I want to deploy it on AWS.
Would I have to deploy React and Node/Express separately? Or could they be deployed together at once?
1. If you have two distinct projects
e.g. a React single-page app and a Node/Express API.
a. You can deploy both separately
the frontend (the React app) on S3 and CloudFront (tutorial)
the backend (the Node API) on Elastic Beanstalk (recommended) or EC2
Another option is to deploy both parts together at once on Elastic Beanstalk or EC2. However, you'll miss out on the benefits of hosting on S3 and CloudFront, i.e. faster delivery for your users and cheaper costs. In my opinion, it's also more convenient and less prone to unexpected errors to update and deploy separately the client-side and the server-side of a web application.
Another benefit of deploying separately: For organizations with different teams for the frontend and backend, it's easier for each team to be able to deploy their side of the application on their own without depending on the other team.
b. Why S3 + CloudFront instead of S3 alone?
all the benefits of using a CDN
your own domain name and a free SSL certificate in 1-click
redirection on 4xx errors (necessary if your app uses a HTML5 History-based router)
the caching system
http2 and http to https redirection
c. How to handle CORS?
You can use different subdomains, e.g.
api.domain.com for the Node/Express API
app.domain.com for the React app
Then enable CORS in the API:
app.get('/api', cors({ origin: 'https://app.domain.com' }), ...)
2. If you have a single project
e.g. a Node app including some React views.
You have to deploy the whole app on Elastic Beanstalk or EC2.
Note: If you have a single project including two sub-projects (i.e. a folder for the React app and another one for the Node API), and if both sub-projects still work when they are separated, then you can deploy the sub-projects separately (see first part of the answer).
3. In both cases
Run your Webpack build before deploying the React part. You can do it manually (before deploying on AWS) or automatically (in your CI/CD system). If you bootstrapped your app with create-react-app (CRA), just run yarn build or npm run build at the root of the project and upload the content of the "build" folder to your S3 bucket.
4. Tools
Official AWS S3 CLI - Manage S3 buckets and objects using high-level aws s3 commands.
Official AWS Elastic Beanstalk CLI - Manage and deploy your backend using eb commands.
S3-deploy - CLI utility for deploying files to S3.
5. If not restricted to AWS
I answered a related question not restricted to AWS.
Basic Concepts
To deploy your app hassle free, you need to learn about three concepts: Microservices, containers, and process managers. I will discuss them with a bit more details and few links to get you started:
Microservices
Microservices is an architecture that allows you to divide your app into smaller services. This has multiple benefits:
1- The services are easily testable.
2- The services are replaceable.
3- The services can scale separately.
Containerization
Almost every useful app has at least dozens of dependencies. You can install dependencies on the target machines, but most certainly you'll face few challenges. Programs like Docker allow you to create a container for your app and deploy that container on the cloud. (Regardless of the cloud provider) Learn more...
Process Managers
Process managers ensure that your app is running smoothly and all parts are healthy. If your app crashes, it can easily restart the app.
1. Deploying a serverless NodeJS / React Application
Note: This approach does not work if you are doing server-rendering with ReactJS. Go to the next option.
You can simply build your app and deploy it to a static S3 website. This option works if you use microservices architecture to separate your API from your react app.
Creating a static website in S3 is really simple:
Create a bucket in S3 with the exact name of the website. Example: blog.stackoverflow.com.
Enable static hosting
Create an A record in Route 53 and connect it to the bucket you created.
For more information check AWS handy documentation.
2. Deploying a NodeJS application into EC2
You can launch different EC2 instances for every microservice. (API, React app, etc.) You need to use a process manager such as PM2 to ensure your app is running smoothly.
Continuous Delivery (Automating deployment)
To create an automatic deployment, I prefer to use Terraform in combination with Ansible. Terraform is very declarative. You describe how the cloud infrastructure should look like and Terraform build it for you.
Ansible, on the other hand, is very procedural and is perfect for provisioning a new server.
Error handling and reporting: Sentry
Ideally, you should have unit tests to prevent shipping buggy code to the production. (Use Jest with supertest, Enzyme for shallow rendering). But the world is imperfect, and it is good to receive any potential bugs that happen on the client. Enter Sentry
Both react and node code can be combined and deployed at once
you can more information here:
How to deploy reactjs and node typescript on elastic beanstalk using eb cli
I want deploy a Meteor application on a wago industrial PLC 750-8202.
Wago supports Boards Support Package with the PTXdist tooling support (Communicate with CoDeSys program on a Linux-based WAGO PFC200 PLC).
I have no idea how i can utilize meteor on such a platform.
Have you any ideas how the steps can be realized to add meteor support for wago plcs ?
It is has linux on it, just SSH to your PLC. Make sure it is connected to your local network.
Now you can install node and everything else. It is like you have your own VPS. Configure everything. You can even install ftp server and upload your files over FTP. Or create small script that will be triggered from Github hooks and update your PLC as soon as you push changes to master branch.