OOOHHH, now that's enterprisey
-
Well yeah, but you can put the API and the web frontend in the same warfile, giving you the API for mobile/smart toaster use and the frontend for web-based stuff
Yes, I know that, but this "microservices" thing is the new rad, so get on board and enjoy the ride.
-
NO. I DON'T WANNA. WAAAaaaaaaa.
Filed Under: What even is a 'microservice' anyways? Aside from something like Skype or Office 365?
-
Obviously I meant exactly 3 lines of code ever for all time. You got me.
You're the one who says everything you say is true, so you kind of ran face-first into that one.
-
Everything he says is literally true except when it's not. Determining which is which is left as an exercise to the reader
-
Just wait for the posts with a lot of CAPSLOCK action.
-
So, I don't really get how this would help you make a mobile app... It's not like you can deploy a .wawwr file to a phone,
That's kind of the point. There's one war that does the back end, and another that does the ui. If you want to do a phone app, you simply write a new ui, in whatever language the phone supports, to talk to the same back end.
If everything was a single application, making a phone app would require doing the ui stuff on the phone, and adding some interface code to the back end, and your phone app and regular app would probably behave differently because they're using different interfaces. You'd also now have to support two interfaces.
-
That's kind of the point. There's one war that does the back end, and another that does the ui. If you want to do a phone app, you simply write a new ui, in whatever language the phone supports, to talk to the same back end.
If everything was a single application, making a phone app would require doing the ui stuff on the phone, and adding some interface code to the back end, and your phone app and regular app would probably behave differently because they're using different interfaces. You'd also now have to support two interfaces.
Ohkay...
But you can deploy the backend together with the frontend. In one package. So......
-
I don't know enough about java to know if that matters or not. Is there a significant complexity cost to having two packages instead of one, or is it just a matter of convention?
-
Well, you'll be running on a different port usually, and the frontend can't make use of any more efficient transport mechanisms than TCP.
Essentially imagine running 2 completely different services versus having them combined into one
It's not a complete and total WTF, but it's a somewhat strange setup if you don't have a reason for it...
-
I don't know enough about java to know if that matters or not. Is there a significant complexity cost to having two packages instead of one, or is it just a matter of convention?
That's what I was asking like 30 posts ago, nobody answered.
-
I don't know enough about java to know if that matters or not. Is there a significant complexity cost to having two packages instead of one, or is it just a matter of convention?
There is some extra overhead, I just couldn't tell you how much.
It may depend on which JavaEE server you're using.
-
Well you're running two seperate http servers. That's overhead. Plus the VM overhead, RAM allocation.... Again, if there's not really a reason to do this, it's kinda a silly idea.
Clarification on wording after re-reading this. When I say "package", I mean the generic term, not a Java package...
-
I don't know enough about java to know if that matters or not. Is there a significant complexity cost to having two packages instead of one, or is it just a matter of convention?
No, or at least it's negligible if you deploy both WARs to the same web server. The main difference is that you will have a URI like http://localhost/myapp-api and http://localhost/myapp-frontend instead of http://localhost/myapp/api and http://localhost/myapp/frontend. Oh, and they will use separate versioning, so any changes in the API means the frontend needs to be kept in sync, whereas a single WAR would be in sync by definition (additional WTFs not withstanding).I believe that was not the original point though. I think @belgariontheking was wondering why they built a REST API and AJAX powered front-end for an internal application with 20 users instead of building just an old-fashioned HTML webapp.
-
Oh, right, you can do that can't you...
Still, in my opinion, it's silly to package your things seperately like that. It lives on the same site, it should be in the same war....
That's the WTF I got out of it, but perhaps @belgariontheking is thinking something else?
-
You guys know it's possible to run two apps on one server right?
We're running one http server and one jboss cluster. The Jboss server != the http server in our case.
It is creating a headache for me having to create two app profiles, deploy two applications, etc. Especially when this was not all apparent to me when it was dropped into my lap.
-
When you say server.... do you mean OS instance or war-serving-application? If it's the first one, major ick...
-
It is creating a headache for me having to create two app profiles, deploy two applications, etc.
That's the sort of thing that ought to be all configured up so that you can do it all automatically from your build-and-deploy scripts. Yes, there might be a lot of bits, but if it's all driven automatically then it's not too big a deal.
Especially when this was not all apparent to me when it was dropped into my lap.
Now we're getting closer to TRWTF… ;)
-
Well you're running two seperate http servers.
Are they? You can run multiple apps or whatever you call those things in the same server.
-
And even if you couldn't, they'd still be sharing the shared libraries.
-
Eh, yeah, I may be wrong. I've never personally operated more than one at a time, so I'm not totally sure how that works.
-
Ah, yeah they like to use a webserver on one box and jboss instances on different boxes. Then the webserver interacts with the app servers and does nothing but push data both ways. As far as I can tell, our jboss server is dedicated to us (for now), so we know the only processing going on there is us. The webserver is shared among all the app servers. Seems to work fine for QA. In PROD, I think the web servers are clusters.
I wouldn't know the beginnings of how to configure it, but I'm glad it works.
-
Ah, yeah they like to use a webserver on one box and jboss instances on different boxes. Then the webserver interacts with the app servers and does nothing but push data both ways. As far as I can tell, our jboss server is dedicated to us (for now), so we know the only processing going on there is us. The webserver is shared among all the app servers. Seems to work fine for QA. In PROD, I think the web servers are clusters.
I wouldn't know the beginnings of how to configure it, but I'm glad it works.
Well, I know you can create reverse proxies in Apache using mod_proxy with the
ProxyPassdirective. Although they may be using an actual proxy program such as Squid or Varnish instead.
-
In IIS, you can put apps inside apps. So you could have
http://happydomain.com/friendlynameandhttp://happydomain.com/friendlyname/api
