I'm a newbie. Im thinking about developing a website that people can be come members of and login. I know that ill need to have a server with a database to store info. What i need to know is, do i just need to create the server host site host it and then have my website hosted somewhere else. To sum up, what's needed in the process of developing this type of site?
No, you can host everything in the same server. Back-end and front-end are words just to describe the organization of your code, being HTML, CSS and Javascript files your front-end, and the rest your backend.
Most host services today have Ruby, PHP and ASP supported by all plans, just as MySQL. There are no need for developing two parts in your application - but you can do that if you want.
I suggest you start by studying what is the MVC structure.
Related
I finished a part of my project and bought a webspace with a domain and a database to publish on. So I create a React-Typescript project with followed structure:
API: has my controllers
BLL: the services
Question do I have to create a Build and publish it on the webspace, with the API, BLL... or only the Web component? So that the API, BLL... are on a seperate server and the fetches from the Web-Component are via IP:Port address?
What is the common way here?
The in and outs of web hosting is massively large problem space. And the strategies and approaches number in the thousands. I couldn't hope to do justice to that in a single answer. But in short, you probably want them on the same server, and you want your backend to deliver your front end assets to browsers somehow. And your frontend makes requests without a domain like /api/mydata/ to pull data from the same domain as the frontend. This question will likely get closed now, as it's way too broad to answer.
– Alex Wayne
We're developing a cloud based web application for customer management. One of the main goals i the capability to connect to different local applications on the customer endpoint.
As example, we don't want to have a customer database in out application, the customer should be able to search within his local ERP system right away.
What we need is not much. Only a client on the customers server with access to the local SQL server as well as the COM model.
But as webdevelopers and mainly going with PHP the question came up, what technology we should use?
I've got two approaches in mind:
NodeJS
Lightweight, Javascript and with the Express and winole32 extension we should have everything we need. But the deployment and installation as a service seems to be a bit wacky.
C# .Net Web API
Also a good approach I guess since the client servers are allways windows. But is there a way without IIS?
Or do you have something completely different in mind? It should be very fast and compact. So its basically just a RESTservice that can be deployed with ease.
Thanks for your inputs and thoughts.
C# .Net Web API Also a good approach I guess since the client servers are
allways windows. But is there a way without IIS
It is called OWIN and it is properly documented (web api self host is a good keyword) and works like a charm. Using that on various services to expose an API into the service.
We are 2 students studying web development.
Right now we are researching and trying to figure out a solution for an ionic app.
the app will have a lot of data content (video, image, music etc)
The questions are: should the APP be developed with a REST api? (seems like the only/best way to connect to a database with ionic?)
or can you build the app with a cloud-based-database without the REST-api (any suggestion for the database?)
and last should we use LocalStorage as our database?
Let me go from bottom to top; if you said you'll use a lot of content in your database - don't even think about local storage. If you really must have a local database as well, consider looking into SQLite (https://github.com/litehelpers/Cordova-sqlite-storage).
The sentence "cloudbased-database without the REST api" honestly makes no sense in Ionic. Let me explain; Ionic uses Angular as its front-end framework. And, front-end is the key word here. You can take any front end framework, or pure vanilla JavaScript for that matter and you will not be able to connect to any database (be it in the cloud, locally, or whereever). It's just not how that's suppose to work.
So, finally, to confirm - yes, you will have to create a (REST) API for your database which will then allow you to "talk to" the database with Ionic.
Hope this clears things up a bit.
Im just in the process of putting together the base framework for a multi-tenant enterprise system.
The client-side will be a asp.net mvc webpage talking to the database through the asp.net web api through ajax.
My question really resides around scalability. Should I seperate the client from the server? i.e. Client-side/frontend code/view in one project and webapi in another seperate project server.
Therefore if one server begins (server A) to peak out with load/size than all need to do is create another server instance (server B) and all new customers will point to the webapi's on server B.
Or should it be all integrated as one project and scale out the sql server side of things as load increase (dynamic cloud scaling)?
Need some advice before throwing our hats into the ring.
Thanks in advance
We've gone with the route of separating out the API and the single page application. The reason here is that it forces you to treat the single page application as just another client, which in turn results in an API that provides all the functionality you need for a full client...
In terms of deployment we stick the single page application as the website root with a /api application containing the API deployment. In premise we can then use application request routing or some content-aware routing mechanism to throw things out to different servers if necessary. In Azure we use the multiple websites per role mechanism (http://msdn.microsoft.com/en-us/library/windowsazure/gg433110.aspx) and scale this role depending upon load.
Appearing to live in the same domain makes things easier because you don't have to bother with the ugliness that is JSONP or CORS!
Cheers,
Dean
I have been attempting to teach myself quite a bit about silverlight, and how it all works, for the past few weeks, and I am to the point in my app development where I would like to connect up to my web server's MySQL database.
My web server is capable of running ASP.NET pages, but is Apache, and natively runs PHP (which is what I'm far more familiar with). It has a MySQL database engine, and I am very well-versed in your typical dynamic page creation with PHP and MySQL.
What I'm NOT familiar with are these "Web Services" that people keep mentioning every time I find an answer regarding the question of "how do you connect silverlight to a database?"...
So my basic question is really one of data FLOW, and where everything fits in the puzzle, and how to get it all working in this particular configuration. Most of the answers I have seen deal with IIS instead of Apache, ASP.NET instead of PHP, and MS SQL Server instead of MySQL.
Also, answers tend to start using abbreviations and acronyms without actually explaining what they stand for.
For example: What is WCF, and RIA services, and how do they fit in to the puzzle as a whole?
I suppose I'm just looking for a top-down overview of the structure of data flow on a MACRO level, not on the micro (code) level.
(Edited to add:)
Also: I have done vb.net apps in the past which have used MySQLConnector.NET to pull from my web server's database remotely, but I understand that the client machine would have to be whitelisted as a remote machine, meaning I'd have to open my MYSQL server up, and make the access mask basically %.%.%.% in order for any client to connect... and that is undesirable... so if I understand things right, the web service runs on the web server, and the client sends requests to it, and the web service acts as an intermediary, grabbing the data from the database (possibly with some sort of "stored procedure" look-alike?), and passes the data on to the client... which also means all database access credentials are on the server, and not inside the (potentially hackable) client...
Do I have it right?
Also, when answering, I need to know where the access to the web services is... in the silverlight APP project code, or the silverlight WEB project code...
I have found this wonderful tutorial that helps to explain it...
http://www.designersilverlight.com/2010/05/23/php-mysql-and-silverlight-the-complete-tutorial-part-1/
Here is how I understand it all working.
There are 3 "Layers" to the process: The application, the web server, and the database.
The application calls out to the web server to execute a script file (like a normal PHP script). There script file can have normal URL variables passed to it (like script.php?foo=bar, so $foo is defined as "bar" in the script)... so you can use those URL encoded variable/value pairs to tweak your script results as you would normally with a web page.
I imagine you would have one script per TYPE of database query, with var/value pairs to tweak your results. So on your web server you would end up with numerous PHP scripts, just like you would normally for a website with different pages, and you pass variables in to those scripts to customize the results.
For example, for users, you could have a get_users.php script that would return all users...
but get_users.php?loggedin=true would get all users that are logged in currently
get_users.php?loggedin=true&ingame=true would get all users that are logged in and in a game... You just script the logic and the resulting SQL query accordingly.
All of the results are encoded either with XML or JSON (Javascript Open Notation: see What is JSON and why would I use it? ) for transport to the app... the app, in effect, is reading the results of an echo of the JSON encoded stuff.
If you were to open these scripts in a web browser, the only thing you would see is a text printout of the JSON data... no web page... just data that is read by the app and then decoded in to objects.
So in effect, the silverlight app is reading a text output of a PHP script executed on your web server, and interpreting the output.
^^^^^ THIS IS THE SHORT ANSWER TO MY QUESTION. :)
To be blunt, the whole use of the terminology "web service" is misleading, and what was really leading me astray. I thought it was some sort of service or app you had to install on your web server just like PHPMyAdmin or something.