First, my html locates things relatively on the server. Do I need to change these to the full urls so it knows I don't mean localhost?
Where is the line between what you package in the app and what you grab from the server? Do you package all of your JS and CSS. Do you also grab scripts from the server sometimes? Do you package images and also grab some images dynamically?
Any other things to keep in mind when starting out a port of a web app to phone gap? Just having a hard time figuring out exactly where the lines are usually drawn as far as assets.
Thanks very much.
Do you care what happens when your user loses his connection to the internet from his phone? If not, then you can reference CSS and images from the server. However, if you use the min version of jquery, you can just embed it all in your application and then you won't have to worry as much about lack of connectivity.
Related
I have started working on a project that needs a re-write. So, instead of doing a big bang release
we have decided to use Strangler Pattern which means the following
The current application (stack details below) will be running as is under the existing domain https://app.com
The existing (and new) features will be re-written in a new stack (details below) and deployed in parallel to the existing app (under the same domain https://app.com)
The requirements are
The end-user always works with the same domain https://app.com
Any existing feature migrated to a new app or a new feature is available by the under the same domain https://app.com
The stack and architecture of the current app is
HTML files with hardcoded data
CSS files
font files
PDFs
images
flash files
among other things.
Thee application is static. It has no database. It makes calls to other 3rd party APIs but does not have its own database (other than the files, and the images)
It sits under a directory and is served by running a web server (Apache) on a private dedicated server.
The stack and architecture of new re-write will
Use React or Gatsby
A standard build system that generates the static files
The data (PDF, Images) hosted somewhere else
Flash files (until we figure out a better way)
Given these requirements, I thought of having 2 versions of the app using some sort of load balancer such as Nginx and serve the URL patterns using a proxy.
For example
a request coming to https://app.com/productPage.html goes to existing app deployment (assuming it is not migrated)
a request coming to https://app.com/profilePage goes to existing app deployment (assuming it is migrated)
Now, considering this situation, I want to ask the following question
Is this approach looks sane? Are there better ways to deal with this situation?
How to implement such a reverse-proxy based system (considering Nginx)? (or if there is a better way)
I would love to hear out ideas and any resources/books/github that can help me learn and implement this.
Thanks a lot in advance!
I would recommend to create a v2 of pages that has been migrated to new functionality. And all links to the page should be updated to point to v2.
If anyone has done bookmark to old links, then those pages can simply redirect the user to the v2 ones by simply redirecting them using JS - window.location(url_of_target_page);
So I noticed when I ran my react app's production build's login screen from create-react-app that all of the source code for the app was available within the static/js folder. Basically, the code doesn't look any different from the code in my ide, on the production build.
I am wondering if there is a way to hide this behind a login screen? So that a user can't directly access these files unless the login is successful. I have looked around and was unable to find anything of use.
The js files from the production build should be minimized which would look a lot different than in your IDE. I assume what looks "the same" is looking at the source using developer tools. The solution for that is to not deploy the source map files (*.js.map). Those are the files that allow developer tools to transform the minimized code back to its original look.
Removing source maps makes it difficult for someone to learn from the code easily, but if there is sufficient motivation to do so, it can still certainly be reverse-engineered. There are also some parts that wouldn't be obfuscated much at all such as the URLs for API calls which would then give someone a lot more information to use as the basis for hacking attempts.
If you need to prevent seeing any version of the source for people that are not logged in, I would recommend building your app as two apps -- one that just contains the login portion and one with the rest. Code-splitting within one app won't do the trick (at least not without using a solution that is quite a bit more complicated to manage than the two-app option), because it just makes the download process lazy and it is still pretty easy for someone to determine what the other files are and download them. However, even splitting this into two apps only helps if you host the second app differently. This will require server-side protection that only serves the JavaScript files for the second app for a user that is logged in. This means either using a different sub-domain for the second app or at least a different directory on the server that has those protections baked in. How you would implement that protection depends on the details of your authentication approach and the technology stack being used on the server. Most likely, it means using a cookie set by the login process and then having the JS files for the second app served up by something that verifies the cookie before allowing the JS files to be served to the browser.
To overcome displaying your source code in production's build, try to build your app with
GENERATE_SOURCEMAP=false npm run build
I develop an angular-php web application which I have it running online, for different users, on 5 different subdomains, such us:
sub1.mydomain.com
sub2.mydomain.com
sub3.mydomain.com
sub4.mydomain.com
sub5.mydomain.com
Problem:
My problem is that I still develop the web-app local and whenever I change files(php, js,tpl.html,css or when add new ones) I have to upload them on each subdomain.
Question:
Is there a way/library/API whatever that I can use to make something like package (with the updated or new files) and just call it from each subdomain url , and make the appropriate updates?
Or should I just copy them to each subdomain?
Do I make myself clear, in other words just like on cms systems that we press the update button and we update a component/module.
If anyone knows a way of doing that please enlight me. Thanks.
I tried to depict what i mean.
What you are describing is called deployment.
There are a lot of ways to create a deployment mechanism so there is not a single answer to your question. Depends of the tools that you are using, the servers where your app is hosted, etc.
If not, I advise you to use Git to make versions of your app (with Github or Gitlab) and automate the deployment process when you push a new piece of code.
You can make your own scripts to deploy or use online services (surely what you need because of "systems that we press the update button").
I can't advice you one particular service but you would find what you need in Googling "deployment automation github".
I would do it with config files. Considering the code for all my substations is the same. I would have config for each sub-domain and fetch the core files from the same location but serving different data If your structure allows it.
I've been looking for a solution to optimize images for better performance.
After trying some solutions (like sharp and imagemin, which resulted in never smaller, sometimes bigger files), I am now looking to experiment with Google's pagespeed. Unfortunately, pagespeed seems to only support Apache and Nginx, which I would not like to add to my stack just for image optimization (also, I would prefer making the optimization once on upload, and not on server request, even if cached).
I will be very grateful for any information that might help me implement this in native node.js, and for any other (working!) image optimization recommendations.
I suggest you only use node for dynamic content (e.g: your application server logic).
For static content, such as images, stylesheets and others... just serve them with a regular web server like nginx. There you can use ngx_pagespeed.
Try npm module lwip.
It's a standalone library(re-built when installing) and no runtime dependencies.
I use its resize and scale operations to create thumb images in my file service project.
Check if this is what you need. :)
I'm developing a simple node-webkit app which is similar to a product catalog. So I have lots of images, around 1500!!
Currently, I'm done with implementing and using Grunt(grunt-node-webkit-builder) for building .exe. After creating an exe file, I use IExpress to make nw.exe and helper DLLs all-in one place. Because some of users doesn't like when setup looks messy. So I have two steps:
Make a build with Grunt
After the Grunt build, use IExpress to make it one .exe
In both cases, all the images are located in the application(around ~250MB).
My problem starts when the users clicks on the application. The time of opening application is around 30-40 seconds! I need to figure out how to decrease time!(btw, in development, it is super fast)
I thought that may be if I get images from external path and caching them make the performance better. But I don't know or I have no idea how to get images from external path after using IExpress!! Maybe there are better solutions or workaround even images are located at internal path. Could you suggest me how to solve this problem? Thanks in advance.
I had the same issue as you and i don't know if you're stuck on this or you found a solution, but searching through the NWJS google group i found this:
var path = require("path");
pathstr = path.dirname(process.execPath);
This returns the path where the NW bin is running. Just treat the string to fit your case and access the external files