I am migrating a single module application into a multiple module application. As part of my deployment process I am setting an environment variable to hold the current QA environment: 'dev', 'stage', or 'test'.
When deploying my old 'default' module, it is able to read this environment variable. However, understandably, the new module 'background' has no access to this environment variable, since it is in a separate process.
Is there an easy way to share information across modules within an application or am I stuck writing app.yaml files for each module multiplied by the number of QA environments?
You have to write a .yaml files for each and every module no matter what - that's what makes it a module :)
However, in general, you can re-use a file in multiple modules by symlink-ing it into the respective modules (personally I prefer to put the actual version-controlled file in the app's dir, outside a particular module dir).
Depending on how exactly you implement the metadata/environment passing you might be able to use a smaller cross-module shared file to complement the module-specific .yaml file (only some of the app.yaml directives can be shared like this, tho).
See for example this Q&A focusing on re-using of the skip_files directive: Do I need to copy `skip_files` across multiple YAML files?
Related
Im in a project where we will create different sites using the same codebase.
I would like to have a brand style and config for each site which I specify somehow in my build process.
Anyone have an idea of the best way to achieve this ?
I would treat the different sites in much the same way I'd treat different environment (dev, test, prod). If there aren't a lot of changes, just use environment variables on each server where the site will run that define which site it is. Your code can then conditionally do things (e.g. add a class site-x to the body for styling).
You can use something like dotenv to make setting environment vars easier (remember Windows does it differently to *NIX) if you're setting environments in a script. That way you're changing a file rather then actual environment variables when you want to test what a particular site looks like.
If there are many different config items that are different between sites then you can have multiple config files (config-site-one.js, config-site-two.js) and a central config.js file that returns the correct config based on some environment variable like MY_SITE_NAME.
However if you actually want to package up the site to 'send' somewhere (?) then you could run your build command with a flag like webpack blahblahblah --site=site-one.
You can use yargs to get that 'site' variable and use it in your build process however you like.
I want to know what're the drawbacks of declaring and using ONLLY ONE module in my SPA?
Does it reduce testability?
Does it impact the performance?
Does it make code less readable or maintainable?
assuming that:
It is single page application
I don't share any block of code to another application
I use browserify to pack all files into one big .js file.
Even if I don't pack all js into one bundle file, isn't it true that all sub-mobules will be eventually depended by the root module? And therefore downloaded from server at the very beginning?
I have an angular constant which defines webservice end point
angular.module('myModule').constant('mywebservice_url', 'http://192.168.1.100')
The problem is that for dev I have a different end point while staging and production its different. Every time I try to check in to git I have to manually reset this file.
Is there any way git permenantly ignore this file but checks out the file while clone or checkout?
Is there any way I can make angular pickup file dynamically from something like environment variable.
NOTE: I don't want to depend on server to do this, ie I don't want to use apach SSI or any of those technologies as it will work only one set of servers.
Delaying the injection via backend processing. I usually just create a global object on html page called pageSettings which values like this is getting injected from the backend, i.e. environment variables, etc. and just pass that global pageSettings object into that angular constant or value.
Build system injection. If you don't have a backend, i.e. pure SPA... maybe you can put this inside your build system, i.e. create multiple task for building the different environments in gulp or grunt and replace that value during the build process.
In e.a. your app init code:
var x = location.hostname;
Then define 2 different constants.
One based off the domain name of your develop environment and one for your production.
I have a bunch of text, xml and other files (i.e. resources) that I need to access using servlets in java web app. For example, there is an xml file, a part of which is returned with a servlet by a user query. I am using Tomcat. What is the best practice to store these files and access them from java code?
1) What are the default folders where should I put them, do I need to put them into Web archive or into one of the Jars?
2) How to access the files from java code? How can I set the path to them so it will work in any environment?
P.S. I've read a number of posts related to this topic, most of which recommend to store resources in jars and access them using java.lang.Class.getResourceAsStream(String). It seems strange because classes and data should be separated.
It's perfectly fine to load static resources using the classloader. That's what ResourceBundle does to load the internationalized properties files for example.
Put them in WEB-INF/classes along with your class files, or in a jar inside WEB-INF/lib, and load them with the ClassLoader as indicated by the answers you already read.
That doesn't forbid you to place these files in a separate directory from the Java source files in your project. The build process should just make sure to put them in the appropriate location for runtime. The Maven and Gradle convention is to put the source files under src/main/java and the resource files under src/main/resources.
One of the things I like about Google App Engine development environment is, I don't have to restart the server every time I make changes to any python source files, other static files or even configuration files. It has spoilt me and I forget to restart the server when I am working with other server environments (tornadoweb, web.py, node.js).
Can anyone explain how GAE does that? How difficult is it to make other servers (at least python based) to achieve the same thing?
You can view the source for dev_appserver.py(link). Looks like ModuleManager makes a copy of sys.modules and monitors each module to track changes based on time:
class ModuleManager(object):
"""Manages loaded modules in the runtime.
Responsible for monitoring and reporting about file modification times.
Modules can be loaded from source or precompiled byte-code files. When a
file has source code, the ModuleManager monitors the modification time of
the source file even if the module itself is loaded from byte-code.
"""
http://code.google.com/p/googleappengine/source/browse/trunk/python/google/appengine/tools/dev_appserver.py#3636
Lot of webservers like GAE, make use of python reload module to see the effect in code change without restarting the server process
import something
if is_changed(something)
somthing = reload(something)
Quote from python docs:
When reload(module) is executed:
Python modules’ code is recompiled and the module-level code reexecuted, defining a new set of objects which are bound to names in the module’s dictionary. The init function of extension modules is not called a second time.
As with all other objects in Python the old objects are only reclaimed after their reference counts drop to zero.
The names in the module namespace are updated to point to any new or changed objects.
Other references to the old objects (such as names external to the module) are not rebound to refer to the new objects and must be updated in each namespace where they occur if that is desired.