Recently I've been playing around with the edge-runtime and finally set things to work normally on my local environment with different routes path handled by some of my custom implementations under fetch event. and these are running under edge-runtime
And with some digging around, to be able to deploy what I've made to Vercel I have to convert my project to nextjs and exposed the config to ensure it to run on the experimental-edge runtime
What I want to ask here is
Is there a way I can deploy my edge-runtime API to Vercel without having to convert my project to NextJS
Thank you
No, Next is required.
use Cloudflare Workers instead for legacy fetch handler support
Related
I would like to enable caching in ArangoDB, automatically when my app start.
I'm using docker-compose to start the whole thing but apparently there's no simple parameter to enable caching in ArangoDB official image.
According to the doc, all the files in /docker-entrypoint-initdb.d/ are executed at container start. So I added a js file with that code:
require('#arangodb/aql/cache').properties({mode: 'on'});
It is indeed executed but caching doesn't seem to be enabled (from what I see with arangosh within the container).
My app is a JS app using arangojs, so if I can do it this way, I'd be happy too.
Thanks!
According to the performance and server config docs, you can enable caching in several ways.
Your method of adding require("#arangodb/aql/cache").properties({ mode: "on" }); to a .js file in the /docker-entrypoint-initdb.d/ directory should work, but keep an eye on the logs. You may need to redirect log output with a different driver (journals, syslog, etc.) to see what's going on. Make sure to run the command via arangosh to see if it works.
If that's a bust, you might want to see if there is a way to pass parameters at runtime (such as --query.cache-mode on). Unfortunately, I don't use Docker Compose, so I can't give you direct advice here, but try something like -e QUERY.CACHE-MODE=ON
If there isn't a way to pass params, then you could modify the config file: /etc/arangodb3/arangod.conf.
And don't forget about the REST API methods for system management. You can access AQL configuration (view and alter) in the Web UI by clicking on the Support -> Rest API -> AQL.
One thing to keep in mind - I'm not sure if the caching settings are global or tied to a specific database. View the configuration on multiple databases (including _system) to test the settings.
I am working on an iOS application that uses a pretty normal multi-environment deployment model. We have a QA, Prod, and "Dev" version of the app that all talk to their own corresponding backends. I am new to iOS development but am familiar with Node, Java, and a few other development environments.
The first thing I reached to for this problem was Environment Variables. I saw that XCode had a way to set environment variables in a Scheme and they could be read pretty easily. So I used 4 environment variables per environment to configure a few needed backend hosts. Everything seemed to be going fine until I realized that those environment variables seem to ONLY be available when running the app through XCode. Is that correct? Is there no way to configure environment variables that "bundle up" with an app? If so, the ability to configure environment variables at all seems like a footgun.
What I mean is, In a NodeJS or Java app, I can set a number of useful "necessary" configs like a backend hosts and use some approach to provide those values when running the app for real. It seems like in iOS / Swift, environment variables are only useful for development-time debugging settings? The asymmetry between what's available in XCode vs a "real" shipped app seems odd.
Is there a similar standard way that I can configure my app for multiple different environments that works on shipped applications and ideally just involves reading some value at runtime rather than using conditionals and/or using compiler flags or something?
You are correct. The Environment Variables are only meaningful when executing the Scheme in Xcode. Their primary use in that context is to activate debugging features that are not on all the time. For example, if you try to create a bitmap Core Graphics context (CGContext) with an invalid set of parameters, the debugger may tell you to set an environment variable to see additional debugging output from Core Graphics. Or you can set environment variables to turn on memory management debugging features.
When you are running an application on a server, the Unix framework in which the application is running is part of the "user experience". In that context it makes sense for the application to use things like environment variables.
As developers we understand that a mobile app is running inside a unix process, but that unix environment is mostly unavailable to us. A similar feature that is common to Unix apps is command line arguments. An iOS application on startup receives command line arguments (argc and argv) but there is no way specify those when the app is launched either.
There are a number of places you could include configuration information like that which you describe in your application. The most common that I can think of is to include the setting in the applications Info.plist. At runtime you could access the contents of the property list by fetching the main bundle and asking for it's infoDictionary:
let infoBundle = Bundle.main.infoDictionary
let mySetting = infoBundle["SomeSetting"]
When the application's info.plist is created, it DOES have access to the environment variables declared in the Scheme so you could put the environment variables in the scheme, reference them in the Info.plist, and retrieve them at runtime from the main bundle.
try Using FeatureFlags, maybe will help you, check this
https://medium.com/#rwbutler/feature-flags-a-b-testing-mvt-on-ios-718339ac7aa1
I'm running Artifactory CPP CE 7.7.3 and Traefik v2.2 using docker-compose. The service is only available over http://localhost/ui/. Now, what I need is an option which allows to add a URL path-prefix (e. g. http://localhost/artifactroy/ui).
My Setup
I used the described setup process from the Artifactory Docs suggest it.
My docker.compose.yaml is the official extracted from the jfrog-artifactory-cpp-ce-7.7.3-compose.tar.gz: ./templates/docker-compose.yaml.
I'm using a reverse proxy (traefik). For this, I've added the necessary traefik configuration lines to the docker-compose-file. Here is a small extract what I've added:
[...]
labels:
- "traefik.http.routers.artifactory.rule=Host(`localhost`) && PathPrefix(`/ui`)"
- "traefik.http.routers.artifactory.middlewares=artifactory-stripprefix"
- "traefik.http.middlewares.artifactory-stripprefix.stripprefix.prefixes=/"
- "traefik.http.services.artifactory.loadbalancer.server.port=8082"
With this I managed to access artifactory over http://localhost/ui/.
Problem:
I have multiple small services running on my server, each of this service is accusable via http://localhost/<service-name>. This is very convenient and want to make clear that this URL is related to this service on my production server.
Because of this, I want to have an URL like http://localhost/artifactroy/ui/... instead of http://localhost/ui/...
I struggled getting artifactory setup in that way. I already managed to get a redirection from typing e. g. http://localhost/artifactroy/ to http://localhost/ui/ but this is not what I want on my production server.
What I did
Went through the documentation in hope of finding an option which I just can passt to artifactroy to add a prefix (Not successful).
Tried configure traefik two full days, to alter headers to get the repose point to http://localhost/artifactroy/ui/... (Only partially successful, redirection didn’t work afterwards)
Tried finding the configuration which is responsible for configure artifactory in $JFROG_HOME/artifactory/var/etc (Not successful)
Is this even possible? Help is highly appreciated..
This example (even though not traefic example) gives you a direction to implement it. There are certain routes already used within the product. You need to add a context over and above it to ensure all comes via the new context path.
https://jfrog.com/knowledge-base/how-to-remove-artifactory-from-the-context-url-in-artifactory-7/
I have a simple CRUD application with backend code in dropwizard. The entire app just comprises of simple resource classes and crud operations except one case where some business logic is involved.
I am trying to extract this into a service instead of putting it in the resource class itself. But for that my service would need an ondemand jdbi connection to access data and do its thing.
All my connect strings and config values are in YML file. Since this app would be running on different servers with different yml files, I dont want to hardcode the yml file name in order to read it again, to get the connect strings and do it that way.
How do I achieve this?
Can you detect what environment you are on?
If so, can you do something like ${environment}.yml?
There is Configuration project on apache which might help.
Otherwise, is it a case of in dev you want to run
java -jar app.jar server dev.yml
and in prod you want to run java -jar app.jar server prod.yml? I imagine you have separate daemons in each environment. So, those environment's will pick up the right configuration, if you've configured them that way.
Otherwise, if the property names are the same, but their values differ, and you pick up the right yml in the right environment, things should work.
If I haven't addressed your question, can you please elaborate your problem a little more?
I am developing a service layer app which provides a catalog of webservices, then I am orchestrating them using OpenESB.
I create my BPELs importing external WSDL definitions using http://localhost:8080/services/myService?wsdl.
The problem is -- these BPELs strongly depend on this specific URL, and when I deploy on production server, my ESB layer stops working.
How can I make my BPELs independent of the specific endpoint? Can I refer the URIs to an external config file?
To do it you must create application configuration and application variable and add them on your http address. Example: "http://${MyHtttpAddress}:${MyHttpPort}/service1/myService?wsdl"/>.
Applications and variable are set up in the administrative console and can be changed for each environment.
Regards
Paul