Yes, I know it is ready for production but I am scared if I use for production I may have some proxy problems or other problems. My plane is to start a blazor server-side project and deploy in IIS, do I need any setting changes in IIS and anyone of you used blazor server-side in production, did you face any problem while deploying?
I don’t have reputation to comment. Server side Blazor is phenomenal for production. Many companies have been using it for a long time. Deployment is the same as any asp.net core app. Checkout www.csharpacademy.com
I’ve also been receiving more contact from companies interested in converting apps to Blazor serverside from asp.net and webforms.
A couple gotchas with server side Blazor:
If your server goes down even for a millisecond, every client is dead. They will need to refresh to get a new connection. This doesn’t happen often in today’s world, but results may vary depending on use-case
I’ve seen with csharpacademy that if you leave the webpage open in a mobile phone for hours in a tab, then come back to it after other tasks, the page is dead and refresh needs to occur.
UI latency is more noticeable for server side. If you have a server in The US and have clients in other countries, they may see more delay. Again, checkout the latency on csharpacademy. It’s hosted in the US and I notice 0 latency with majority of clicks/interactions.
One last comment,
If you’re unsure of whether to use server side or clientside, I’d encourage you to try and build your app with flexibility in mind. Create a razor component library and put all your components/logic in there so that you can share the lib between a clientside and a server side app.
Cheers!
Related
I've got an app that's been started on the Microsoft stack as a smart client (notionally WCF/WS enabled) with a small client app that gets deployed and the rest of the app running in our private cloud. It's only real dependency is internet connectivity, .net 4 and a windows operating system.
I am under pressure to convert over to a browser based architecture for all future development. Based on other web apps I've worked on, I'm concerned that the way that client IT organizations can control the browser, it will cause more problems down the line than what I really want to deal with.
Do you have experience making this kind of decision? What technical factors did you consider when deciding to go smart-client vs. browser? What resources were helpful in making this decision?
My app is a healthcare app targeted at healthcare providers (eg. hospitals), so everywhere I go, I have to worry about the Healthcare CIO looking over my shoulder.
Interesting. Originally I'm from C# winform and WPF Desktop programmer, and later being assigned to do web development. Haven't touch Smart Client yet but I think it should almost be the same with Native app. Based on experience, the technical things to consider are:
Multi browser support
Especially for reporting and graphic processing, without some library / plugins / framework for your component, it will be insanely hard to keep your app multibrowser. Especially in css style and less in javascript.
Client programming(javascript)
You will lose the ability to create controls and animation using C# controls. Instead you must using javascript (jquery or other library) in exchange. Javascript is not fully OOP, and intepret language (no compile error), making it harder (maybe there is some framework like coffeeScript which I haven't yet explore). In addition, it is harder to make since it will need server request / response activity in between the process, which I will describe later.
Request / Response Client-Server Architecture
This means that most process in client will need to request for the server (request for data to display, request to modify the data, etc). It also means that you lose the ability of control event, even if you use asp.net webform (it still need some tweaks for the event to work). However I assume you already used the WCF so this kind of architecture must be that hard.
Security
Don't keep important information such as password, etc in client (hidden field, javascript variable, etc). The concept should be the same with multitenant client, however in browser, user has free access to debug your webpage.
Concurrent and Multithreading
In browser, it is easier for multitab page and concurrent process will be very highly to occur. Your code must able to handle the multi threading for client side. For server side, you can still use your WCF to handle concurrencies.
My 2 cents.
Obviously the web application has its own challenges. I hope this link can help you in some aspects: http://msdn.microsoft.com/en-us/library/ee658099.aspx
Along with those you need to focus on non-function requirements like extensibility and scalability etc. too.
What I want to build is an application that sits online and it's used by different groups that each have their own intranet. Now, because of a stupid security policy the data can't sit outside the intranet. How would you go about building an app that it's still online, so you can push updates to everyone at once, but has a DB on each intranet's server?
My initial plan is to use Node.js and MongoDB.
If your db really has to be onsite, and your app really has to be offsite, then probably your only option is to set up a secure connection from your app, to the onsite db, and pretend as if its hosted locally to the app. This may/may not violate the security policies. You could in theory lock it down pretty well, with a vpn between the two networks. But this is not for the faint of heart, performance will suffer, and it does have security issues. It also means a bit of work for every site.
If the only reason you're wanting it to be "online" is for pushing updates as you stated, then you'll do better installing the app on-premise, and getting it to poll into a central server for notifications about new versions, download updates to itself, and install them automatically. Once you've created this, a new installation requires no new work.
I'm facing a similar problem right now, so here's my take on it, not really mongo or node specifc.
Put a db and a simple restful server on each of client's intranets. Servers can be exactly the same.
Put a routing facade accesible from internet that redirects requests to apropriate server based on url, ie: http://facade/server/resource becomes a request to http://server/resouce.
Configure the facade so that a requests to http://facade/resource go to each server, retrieve results and return all of them in some aggregated form.
Obviously there are more details to take into account, like permissions (can everybody publish to each server? if not, who can?), but the general idea is there.
I am currently working on a project where we have developed a portal on SharePoint. Currently we have two servers which is using Load Balancing. We're experiencing a lot of difficulties connected to this, so we are thinking about removing one of the Web Front-End servers from the farm.
Could this cause any kind of problems that you can think of? I want to be sure before I recommend to this to our client. Anything you could think of would be great. Also pro's you can think of by doing this is appreciated.
The load balancing was agreed on from the beginning of the project, before we came in as consultants.
(I know this could be posted on SharePoint.Stackexchange aswell, but this could be general knowledge for anyone else as well.)
Since "two servers" is not a good idea anyway (you'd normally create at minimum a three server farm - two load balanced web front-ends and one indexing/job server), you can easily merge them into one server. Steps would be like this:
- enable all the services on the server which stays there
- remove the other server from "web front-end" role
- uninstall sharepoint from the other server
This might require recreation of your shared services provider if you are hosting some of the SSP things on the server you are removing.
How can I diagnose timeout problems and slow page loading with my site, I have ySlow plugin in firefox and it shows that grade A/B for most pages so i would expect pages to load quickly. Should I contact my hosting company? The company I bought my domain name from? There is not much load on the server at present and I am using a v. fast connection to connect to the internet.
wheres a good place to start? How can i monitor this when we start seeing more traffic? Should hosting company be doing this?
The first step is to establish whether the problem is client-side or server-side.
A good YSlow grade indicates the problem probably isn't clientside. YSlow checks to see that you don't have too many objects on the page, that you have minified your javascript/CSS etc. It does not evaluate the performance of your network or server.
Using YSlow/Firebug, check to see how long it takes to load the actual HTML of your page. If that is taking a long time, then the problem is almost certainly with your server, network or server-side code.
To rule out network issues, compare accessing your site from the server itself to accessing it over the internet. If it's a lot slower over the internet the problem could be network-related.
If it's not client-side or network-related, then it's either that your server is struggling for resources or that your code is slow (perhaps because the amount of data it is mananaging has grown).In that case, check the server logs and run a profiler on your code (on a development server but with a copy of production data).
Tools like YSlow will point out some opportunities for optimization but they don't acrually measure performance and they don't look at how long it takes for things to happen.
Try something like WebPagetest which will give you a browser-view of the page loading and you can work through the waterfall to see where the time is going.
If you are seeing timeouts then it's probably a back-end problem (will be pretty clear in the waterfall) and you're going to need to instrument your server to figure out where the time is going. If it's a dedicated server or VPS then you can install something like New Relic and it will point out the problem pretty quickly. If you are on shared hosting then you're going to have to add logging to your app directly (there are plugins that can do this if you are running something like Wordpress).
The first place to look would be the server logs , that should provide you a clue as to what is happening and how much time a request is taking in general .
If the server is returning fine and the page is taking long because of client side code , you might want to use the Firebug profile to profile your page and find out more .
Hope this helps .
Want kind of pages are you trying to load? Plain html or scripts like PHP? If plain html I guess its your hosting company.
I've been developing web apps for over a decade now, all the way from CGI to ASP.Net and Struts+Spring+Hibernate. The prevalent architectural style seems to be server-assisted MVC, e.g. Struts, Ruby on Rails, etc. Recent developments lead me to ask if these are on the decline.
Adobe's AIR and Flex
Microsoft's WPF and Silverlight
Google's Chrome and Gears
SOFEA and SOUI
All of this leads me to believe that we're starting to come full-circle after a 15-year distraction kicked-off by the invention of the web. Over this period of time, we've been so fascinated by all the web has to offer that we didn't notice that the usability (and the developer experience) of web apps pretty much sucked in comparison to desktop apps. It seems we're now saying "Screw this! We love the web's benefits but we also want better usability, offline capabilities, and better integration with the desktop!".
All of the above mentioned developments seem to be moving us in this direction of putting the presentation logic back where it used to be: the client. Don't get me wrong, I don't think server-assisted MVC frameworks are going away anytime soon, but I do think they are on the decline and RIAs and RDAs are on the rise.
So, what do you think? Are server-assisted MVC frameworks near their peak?
I agree, to a point - we are becoming are more client-centric, but I think this is because the clients are actually advancing in a standardized way.
We started out with everything on the client - because thats all there was. Then it was client-server, which separated the two, then gradually the client bit was thinned out and pushed back to the server, for one reason:
clients sucked (win95, macos<10, unix X11), and deployment was a nightmare. Deploying a browser was trivial.
Thats changing tho. Air is an easy install, as is .NET 3.5. Air apps are easy to deploy (click here - say yes!) as is a WPF Click-once app. The network is now a defacto part of the environment, not something special that had to be added. A database is something you can embed into a silverlight app (SQL Server Compact Edition), or an iphone (SqLite), not something you have to have a big server for.
and everything has auto-updating, which makes the post-install story a lot better.
I dont think they are on the decline - I think the logic has just been pushed out again, and it'll be pulled back in the future, only to be pushed back out etc.
Silverlight/Air/Flash etc are all very powerful, but HTML + Javascript, which is the basis of the server MVC frameworks, has come forward massively, esp if you ignore the b'stard that is IE6.
Regardless, I'll still be writing the backend for RIA's in a server-assisted MVC framework, even if they are throwing out JSON, not HTML. So while they are no longer the be-all, they are far from dead (or peaking)
Lets clarify something!
MVC is only a design pattern for the seperation of concerns. There is no really relation to server side frameworks.
There is no technical Web 1.0 or Web 2.0 ... JavaScript and Flash were there for years. It's only about social networking, tagging etc.
The server side frameworks are not dead at all. I agree with Nic Wise in case of the bad client architectures/rendering. Can you print a HTML page (every time in the same way)? No, you can't, because every browser(-engine) has it's own representation your HTML description. Only because JavaScript/Flash... are restrictions for a lot of people/companies, the server side processing will stay there for a long time.
Developing "Run anywhere" JavaScript has been a burden for a long time! Nowadays we have Frameworks like JQuery which do this job for you. I've written my own homepage in JavaScript, using EJS (Embedded JavaScript) for the templates/mvc. The old bloated JSP/PHP pages have shown, that differing the business logic from the design is a really good thing.
A bad problem of every web application is to decide, where you save the state of the application! If you choose a bad way, you are not able to scale. Client centric frameworks with service oriented backends allow you to scale very good.
I have been working a little bit with SOFEA/SOUI. If you have an ready framework stack for the most common problems, you'll love it.
Air and Flex are nice, but they bring in a lot of restrictions (Flash/JS...).
Google's Chrome and Gears need you to install Google software at your computer. Who has Gears around here? Gears hasn't established as a wide distributed standard.
If you have experience with Hibernate/Spring and Struts, you sould try Grails! It is nice to develop GWT/FLEX&AIR/SOFEA&SOUI backends and also for the good old server side HTML rendering.
I like SOFEA/SOUI because it isn't such invasive, it offers an investment protection (SOA services) and high rate of reusability. It's also a nice way to move the load from your server to the clients.