The situation I met is that.
I design a frontend app by React, but I want to connect to MongoDB.
From what I knew so far, I could only connect to MongoDB in the backend. So, I use the express to set up a server but when I try to connect the frontend to the backend, the answer I found seems to tell me that I should run the server and the app on different domains, so I should run the server and app on different Heroku apps.
Could I put the server and app in just one Heroku app and connect between them?
I'm currently developing a web apps for my client, and my development server (a shared hosting server) only support MySql. But I just came to know that my client on whose server I'm going to deploy the laravel web apps on only support Mssql.
So my question is, later when I deploy the laravel web app on my client's server, what should I do to make the web apps works perfectly well? Is it enough if I just change the default driver from mysql to sqlsrv?
I built an app to offer a client of the company I work for that I deployed to Firebase. It uses Firebase storage for retrieving files as well as the realtime database. It's actually just the front-end portion of a two-app suite I made; the backend portion is used by an admin for uploading files, checking data, etc --- which data then becomes available to view over the frontend. Both use firebase.
It turns out the devices that would need to access the app (tablets mostly) are inside of an extranet with a server that can establish VPN connections only. Now I'm being asked how I can build the app so these devices can access the app.
I don't know much about the inner-workings of Firebase but it seems to me I may have couple of options:
1) Figure out how to make the FB database accessible over VPN (preferable)
2) Reconfigure the app to use something like MongoDB. Instead of deploying on a remote server, let the on-site server service the devices using the app. Send files that are needed by the server via FTP over the VPN, then process these files on-site.
Problem: I'm using a Mac and the on-site server uses Windows. It will be a pain to install things on a Windows machine remotely, let alone set up the VPN.
Any ideas? I'm sure there are parts of this question where I've made wrong assumptions --- I've never needed to do things over a VPN before.
we want to connect the Azure database by using console application. my application sheduled in system it has dynamic IP. so i have problem to connect Sql Azure.
then developed a webservice and hosted in windows azure and consumed the web service from console still we have same issue.
please suggest
If you know the IP range, you can allow the entire range on the database firewall. It's not very elegant but will work.
This question has probably less to do with actual programming and more to do with environment setup.
I'm developing an application for a Windows CE device, which will use a service hosted in Microsoft Azure. Obviously, this is all under development, and the service itself has not yet been uploaded to Azure. So I'm using the emulators provided by MS to deploy the service locally. Also, I don't think uploading the service to Azure just to debug it is a good idea, as that could net us a bill for Azure we don't yet want to pay.
Also, please note, I'm using VS2008 for the Windows CE project and VS2010 for the Azure project (thank you MS for dropping support for mobile devices -_-).
The problem is, the service seems to be accessible only via 127.0.0.1 or localhost, and if I physically connect a Windows CE device or use an emulated one, it becomes a new entity on the network, and cannot access that service any more.
How can I debug my Window CE application and have it see the service, whilst still being able to debug the service itself?
You are correct, the development fabric (the compute emulator that allows you to build an azure application and debug it locally) is only meant for local development. There are some hacks that allow you to get around that, but I wouldn't recommend it.
My recommendation would be to spin up the service in a more traditional hosting environment, at least in these early stages. You can define it as a web app just as you always would have, and get it functioning. Then, when you know its mostly complete, create a cloud service project and do an add existing to bring your web app into the cloud service solution. Once in, its a simple matter to add the web app as a web role.
From there, you can complete testing of the service in both the local and hosted azure environments as needed. This allows you to minimize your development costs while still leveraging the power of the cloud. As an upside, you also have done most of the basic work to ensure your service is compatible with multiple deployment scenarios giving you a greater degree of choice for its final production state.
OK, I don't know if this was intentional, or if I found one of the mentioned hacks, but I saw that IIS hosts the Azure site I created on port 5100, and the binding for this site is *, so it accepts all connections.
Using this I could access the service from my emulator, and I could still debug all Azure related stuff.