I am building a proof-of-concept line-of-business Single Page App. I want to use ASP.NET web api for the REST service layer, and Backbone.js and Require.js on client. I would like to use modular structuring of js files and templates (Require.js) so the source code of the app would not end up in one html page.
I havent found an example how to lay out the project in Visual Studio, and what project type should I choose. Should Web Api be in one project, and web application in another, or should it be mixed. Any advice or best practice would be very appreciated.
Thanks!
What I did previously for the same goals was to put the WebApi and Web application in the same project. It makes thigs easier from the point of view that you will everything set up when you create the project in Visual Studio.
There is a slight problem in having the webapi in a different project: since you have to put that on a separate hosting or eventually on the same hosting but bound on a different port or virtual directory, it may need some time setting up IIS... eventually in the past we used the Url rewrite module to redirect calls from the Web App to the Web Api application. There may be simpler settings but again it will require a bit of time, depending on your confidence in setting up IIS...
For starter/proof of concept probably having everything on the same application will make things smoother. You may want to keep Domain Models and DB access in separate projects so if eventually you end up splitting the WebApi from the Web App you can still reference those two without problems.
In the end, the Web Application will only have one controller with one action (Home/Index maybe) and this will be the point of contact that will deliver all your html/css/js to the client. Being a SPA, everything from now on will be managed by Backbone on the client (navigation too), with the occasional call to your JSON Web Api endpoints to get and post data.
Related
Let's say I have an API that I charge people to access.
I want to create a "reference" web app that other devs can integrate into their own website, which consumes data from my API.
Are there any architectural choices I can make that will simplify the use of my webapp for these other devs?
The reference web app will probably be implemented in Angular, but the sites it gets integrated into could be using any web frameworks (or none at all).
I can bundle up all of my javascript and css into single files, and I can ensure that I'm not polluting the global javascript namespace. Anything else I should be thinking about?
I'd like to build a new single page app using Rails 4 and Angular and Capistrano for deployment process.
I want all the front end to be a static app on Amazon S3, but I'm openminded for other suggestions.
What's important to me is a fast developing process with the ability to scale up easily.
I was wondering what is the best structure I should use:
keep all assets in app/assets and set Bower path to vender directory.
that way i can use rails precompile methods and enjoying Rails html tags for index.html, but i'm sure it will be easy to upload it to S3 and keep it separated.
keep all assets including Bower components in public/app directory, which will keep it as a complete separate application, but then i need to use Grunt or any other service for precompiling assets.
any other idea?
From my experience, I found this approach to work really well:
API app (Rails/Sinatra/Grape/Node/whatever) serves only JSON APIs. Deploys to a server, say api.yourapp.com. Serves Access-Control headers.
Static web app: started by generating with yeoman an AngularJS, Gulp, Bower app. Deploys using gulp aws deploy module to S3.
There's no real reason to have both views and apis in the same app or built with the same technology (as in Rails).
Now there are issues:
S3 doesn't support nicely Angular's HTML5 mode URLs. So pure S3 website isn't an option.
Facebook doesn't read OpenGraph tags that are not in the source of the page.
Couldn't figure out the state of Google/SEO and Angular apps. I didn't see the content in the search results.
So as a solution I introduced another web server app. Can be based on anything - pure rack, node etc. I chose rack.
Solutions to the problems:
Web server app was hosted on www.yourapp.com and proxied (and cached) requests to S3. It supported all URLs (html5Mode) - just proxied to index.html.
OpenGraph meta tags - the API had an endpoint that gets a URL or ID of an object and returns meta tags information. Web server issues a request to API once per URL (caches the response) and injects it in the served index.html.
SEO - as a middleware, used prerender for rack that rendered pages on the server.
As a bonus -
Most apps today have a landing page/marketing site and the actual app. Sometimes it's better to maintain these separately. The web sever knows according to a cookie which app to present on www.yourapp.com - actual app or marketing site. On sign in - set a cookie on client side and voila.
First, I think there's a bit of a confusion here, let me try to clear it up.
There are a couple of ways for achieving this
Pure client -> API
When you have a static application, there's no need to go through the Rails asset pipeline, there are far better ways to manage assets when you are using the tooling for client side applications.
For example, your client application will be an Angular application and you will manage assets with a combination of bower (dependencies) and grunt (build and distribution).
There's no point of deploying to S3 with Capistrano, if it's a pure static application, you can use aws CLI in order to just upload your content.
I'd go through a CDN as well. Something like Fastly works really well over Amazon S3.
I have a Rake task that uploads to S3 and then clears the cache on Fastly (if I need to).
As for your Rails application, it would act as an API, it should not have any assets
Combined
If you have a combined application, some of the actions are served by the server (Rails) and just invokes some client side code (Angular).
If this is the case, I would go through Rails asset pipeline and just keep everything as Rails best practice with compilation pre-deploy etc...
It's one of those questions where "it depends" is the answer really, it all depends on what you want to achieve.
When I have a client application, I try to have a pure client and have the server only as an API, with no assets at all, this way, I separate the concerns.
EDIT 9/9/15
I'd have to say that as long as you can, I'd keep the apps separate.
It's not always possible, especially with more complex apps.
Most apps I have seen in the recent months have kept the client side and the server side code separate, I have seen less use of rails and more use of rails-api because of that (some even ditched rails completely for thinner solutions).
So in my quest to learn front-end development (doing server side, WCF, etc for the past 4-5 years), I managed to create a simple little movie app just using javascript and html. When I created this app, I was using Sublime Text and since I'm a .NET developer, I'd like to move this site over to Visual Studio and actually wire it up to WebAPI or MVC and start talking to a database.
What is the best way to move over a pure html/javascript/css site into Visual Studio and wiring it up for db connectivity? I thought about just creating a web site project in a solution and start wiring it up to a BLL and DAL layer but I didn't know if that was ideal or not.
Any help would be appreciated.
Thanks!
IMO Your best bet is to create an empty WebAPi2 project in VS and create a folder called 'app' that you will move your Angular files into.
Right click your project and go to the Web tab. Set the start page to whatever HTML file is your main page.
You should now be able to just F5 and run the application. Then start creating WebApi controllers for your data layer and you should just able to hit the API from localhost/api (or whatever you designate in your routes)
AngularJS should be completely independent of the server language (php, c#) and server (nginx, apache, IIS) you run it on.
I have worked on angular projects that talk to C# WCF services and are hosted on IIS just fine. You best bet is to create restful services in WCF and use angular services and factories to pull that data into the client angular app.
I think the best place to start would be the $http service of Angularjs.
https://docs.angularjs.org/api/ng/service/$http
I have currently a visual studio that contains 3 projects :
MyApp.Models : Contains all my models with Code-First migrations
MyApp.Web : Contains my main website, only with MVC
MyApp.Pass : Contains a subdomain website, for customers.
We have new projects and we need to have those things :
A WebAPI that can be consumes by my main website, my pass website, a backoffice website, and a mobile application
a backoffice website that consumes WebApi, built with AngularJS
A mobile application that consumes WebApi, built with Xamarin
How can i layer my visual studio solution to only have one WebAPI that can be consume by all my differents websites/mobile app ?
Best regards,
I am currently building a side project - viewingbooker.com which is exactly the setup you are looking for.
What you need to bare in mind is that web api and mvc website have 2 different authentication techniques. Web Api 2 makes amazingly easy to authorise users from eg. xamarin mobile apps. Token is issued and is generally valid for 14 days of inactivity.
I have few projects within my solutions. Most importantly you need a separate project for your business logic. I also use DI to test my business logic as I go.
For website, I serve data as JSON from standard Controllers. For my mobile app, I have a separate web api project that serves the data separately. They both use business logic project so it keeps code redundancy to the minimum.
Remember that mobile app is not a website which you can quickly fix. If you end up using the same models and controllers for website and mobile apps, any change you make will brake your mobile apps and not all users have auto upgrade feature switched on on their mobile devices.
So I recommend you have a standard website with its own models and controllers, which is consumed by angular/knockout etc. Web API 2 project with its own models and controllers. Business logic project in the form of different services accessible by its interfaces so it's easier to test it. And don't get too paranoid with code redundancy that is different controllers, models for website/mobile. This approach will save you a lot of headache in the future - talking from experience.
I have an AngularJS SPA served up as part of an ASP.NET MVC application. Within this I have an Angular factory which accesses a REST API elsewhere on our intranet. We have various instances of this API for development, production and UAT. I'd like to be able to configure the URL of this API within something like the web.config so that when I build each different solution configuration the correct URL is provided to the factory.
Unfortunately I'm working within an environment where I cannot use npm (it's complicated - suffice it to say that NTLM proxy authentication combined with a smartcard login don't play nicely with npm), so a lot of front-end build tools that seem like they might have been helpful aren't available to use.
Currently I'm just thinking of adding a method on a controller which returns a value in the web.config, but this doesn't seem terribly elegant. Perhaps there's a better way?