Re: Looking to fit Clojure into my architecture and am in need of your informed advice!
Hi! A big thanks for both of you! I will start experimenting with a Clojure and Compojure based REST JSON web service which takes som data from PostgreSQL. Although graph databases looks interesting too, I will surely check out neo4j (I've actually been eye balling it previously too) and try some code out on it too. I'll let my experimentation phase drag on for a while. Until I get an architecture which I believe in. And is fun. :-) (for my motivation.) Thanks again for helping out! If anyone has any more tips I'll all eyes! Best regards, Kent On Mon, Aug 2, 2010 at 10:20, nickikt wrote: > Just a little add on to Clojure on Google this is a blog of a company > that uses Clojure for a project and the have a DSL for Bigtable. > (There is a second blog with only talks about Clojure on google app > engine as well) --> http://www.hackers-with-attitude.com/ > > On Aug 2, 8:47 am, Saul Hazledine wrote: >> Hello Kent, >> >> On Aug 1, 2:00 pm, Kent Larsson wrote: >> >> > I'm planning to reduce my time at my full time job to create a small >> > startup. And I am thinking about create a lean and mean architecture >> > which will enable me to get things done. >> >> Cool! >> >> > I am thinking about creating a layered architecture like this: >> >> > 1. Front end >> > 2. Business >> > 3. Database >> >> > I think that the "2. Business Layer" should be Clojure. It would talk >> > to the "1. Front End" by a web service REST interface. Exactly how the >> > data should be encoded is something I haven't though about yet. But >> > JSON seems like an easy format. >> >> Building a JSON service in Clojure and Compojure is easy to do. >> >> > My idea is basically to create a good Customer Relationships >> > Management (CRM) system and sell it as a service to companies. The >> > users will input information about customers and related events and it >> > will be easy to search. I'll have quite a lot of business logic which >> > makes these tasks easier. The logic will most often be stuff which >> > handles graphs (which SQL really has some problems handling nicely). >> >> I've not used it but neo4j looks like it might be worth looking >> at:http://neo4j.org/ >> >> > Some must have goals: >> >> > 1. If it becomes a success, it needs to be able to scale over multiple >> > machines with load balancing. There will be some data which should be >> > replicated between the machines, but a delay is all right. >> > 2. As I sell it uptime is important. If I have several machines and >> > one of them dies. I'd like the service to be available using the other >> > machines. >> >> Some people have had success getting Clojure running on google app >> engine. You get scaling for little effort but the BIG downside is that >> your app can take over 10 seconds to respond when nobody is using it >> (when under load the app runs at a decent speed). >> >> > My questions: >> >> > 1. Do you think Wicket is a good choice for the front end for me? It >> > has session state on the server which I need to replicate in more or >> > less real time. If I have the state on the client using JavaScript I >> > don't have to deal with that replication. But how would I achieve that >> > in the most smooth way? Should I go for Compojure for the front end to >> > not have to deal with two languages? And then maybe skip the >> > separation of layer "1. Front End" and "2. Business"? >> >> I've not used wicket. Compojure/Hiccup are wonderful, will handle >> session state no problem, but they aren't a full web framework. You >> will have to do extra work compared to say Ruby on Rails, Django or >> Grails where you can get a front-end up in a weekend. >> >> > 2. Will it be hard to write a nice web service interface in Clojure? >> > Is it a suitable communication strategy with Clojure? Maybe I am >> > making it too complicated? >> >> Web services are easy in Clojure/Compojure (that's worth saying >> twice). >> >> > 3. Clojure has a lot of nice stuff for handling data in transactions. >> > But if all my data resides in a database will I get to really enjoy >> > this advantage? I have been thinking about actually storing the data >> > using Clojure and skip the database, to get more out of Clojure. Is >> > that idea too crazy? I will have to deal with data replication myself >> > then, or maybe something like memcache will solve it for me? >> >> Personally, I'd stick with some sort of database as it will have been >> designed to protect your data from accidents. Clojure has lots of >> advantages even if you don't use the concurrency features. >> >> >> >> > 5. Is it hard to debug Clojure? Using Java/C# today you get a real >> > treat when it comes to debugging with interactive stepping, expression >> > watching and a lot of other cool things. Where is Clojure debugging >> > compared to other languages? Is the debugging features as necessary as >> > in other languages? >> >> Conventional debugging is harder at the moment but having a REPL or >> using swank means there is
Re: Looking to fit Clojure into my architecture and am in need of your informed advice!
Just a little add on to Clojure on Google this is a blog of a company that uses Clojure for a project and the have a DSL for Bigtable. (There is a second blog with only talks about Clojure on google app engine as well) --> http://www.hackers-with-attitude.com/ On Aug 2, 8:47 am, Saul Hazledine wrote: > Hello Kent, > > On Aug 1, 2:00 pm, Kent Larsson wrote: > > > I'm planning to reduce my time at my full time job to create a small > > startup. And I am thinking about create a lean and mean architecture > > which will enable me to get things done. > > Cool! > > > I am thinking about creating a layered architecture like this: > > > 1. Front end > > 2. Business > > 3. Database > > > I think that the "2. Business Layer" should be Clojure. It would talk > > to the "1. Front End" by a web service REST interface. Exactly how the > > data should be encoded is something I haven't though about yet. But > > JSON seems like an easy format. > > Building a JSON service in Clojure and Compojure is easy to do. > > > My idea is basically to create a good Customer Relationships > > Management (CRM) system and sell it as a service to companies. The > > users will input information about customers and related events and it > > will be easy to search. I'll have quite a lot of business logic which > > makes these tasks easier. The logic will most often be stuff which > > handles graphs (which SQL really has some problems handling nicely). > > I've not used it but neo4j looks like it might be worth looking > at:http://neo4j.org/ > > > Some must have goals: > > > 1. If it becomes a success, it needs to be able to scale over multiple > > machines with load balancing. There will be some data which should be > > replicated between the machines, but a delay is all right. > > 2. As I sell it uptime is important. If I have several machines and > > one of them dies. I'd like the service to be available using the other > > machines. > > Some people have had success getting Clojure running on google app > engine. You get scaling for little effort but the BIG downside is that > your app can take over 10 seconds to respond when nobody is using it > (when under load the app runs at a decent speed). > > > My questions: > > > 1. Do you think Wicket is a good choice for the front end for me? It > > has session state on the server which I need to replicate in more or > > less real time. If I have the state on the client using JavaScript I > > don't have to deal with that replication. But how would I achieve that > > in the most smooth way? Should I go for Compojure for the front end to > > not have to deal with two languages? And then maybe skip the > > separation of layer "1. Front End" and "2. Business"? > > I've not used wicket. Compojure/Hiccup are wonderful, will handle > session state no problem, but they aren't a full web framework. You > will have to do extra work compared to say Ruby on Rails, Django or > Grails where you can get a front-end up in a weekend. > > > 2. Will it be hard to write a nice web service interface in Clojure? > > Is it a suitable communication strategy with Clojure? Maybe I am > > making it too complicated? > > Web services are easy in Clojure/Compojure (that's worth saying > twice). > > > 3. Clojure has a lot of nice stuff for handling data in transactions. > > But if all my data resides in a database will I get to really enjoy > > this advantage? I have been thinking about actually storing the data > > using Clojure and skip the database, to get more out of Clojure. Is > > that idea too crazy? I will have to deal with data replication myself > > then, or maybe something like memcache will solve it for me? > > Personally, I'd stick with some sort of database as it will have been > designed to protect your data from accidents. Clojure has lots of > advantages even if you don't use the concurrency features. > > > > > 5. Is it hard to debug Clojure? Using Java/C# today you get a real > > treat when it comes to debugging with interactive stepping, expression > > watching and a lot of other cool things. Where is Clojure debugging > > compared to other languages? Is the debugging features as necessary as > > in other languages? > > Conventional debugging is harder at the moment but having a REPL or > using swank means there is less need for debugging anyway. You can > play with each function as you write it. > > > 7. Any other advice or thoughts you have about this? > > I wouldn't worry too much about scaling. Making an application > scalable is a lot of work (unless you're using something like Google > appengine). Computers are much faster than they used to be. A single > machine running Jetty/Compojure with a database such as H2 will handle > 100's/1000's of pages per second. If you exceed this your business > will be very successful, you will know your application better and > then you can concentrate on scaling. > > Saul -- You received this message because you are subscribed to the Google Groups "Clojure" gr
Re: Looking to fit Clojure into my architecture and am in need of your informed advice!
Hello Kent, On Aug 1, 2:00 pm, Kent Larsson wrote: > > I'm planning to reduce my time at my full time job to create a small > startup. And I am thinking about create a lean and mean architecture > which will enable me to get things done. > Cool! > I am thinking about creating a layered architecture like this: > > 1. Front end > 2. Business > 3. Database > > I think that the "2. Business Layer" should be Clojure. It would talk > to the "1. Front End" by a web service REST interface. Exactly how the > data should be encoded is something I haven't though about yet. But > JSON seems like an easy format. > Building a JSON service in Clojure and Compojure is easy to do. > My idea is basically to create a good Customer Relationships > Management (CRM) system and sell it as a service to companies. The > users will input information about customers and related events and it > will be easy to search. I'll have quite a lot of business logic which > makes these tasks easier. The logic will most often be stuff which > handles graphs (which SQL really has some problems handling nicely). > I've not used it but neo4j looks like it might be worth looking at: http://neo4j.org/ > Some must have goals: > > 1. If it becomes a success, it needs to be able to scale over multiple > machines with load balancing. There will be some data which should be > replicated between the machines, but a delay is all right. > 2. As I sell it uptime is important. If I have several machines and > one of them dies. I'd like the service to be available using the other > machines. > Some people have had success getting Clojure running on google app engine. You get scaling for little effort but the BIG downside is that your app can take over 10 seconds to respond when nobody is using it (when under load the app runs at a decent speed). > My questions: > > 1. Do you think Wicket is a good choice for the front end for me? It > has session state on the server which I need to replicate in more or > less real time. If I have the state on the client using JavaScript I > don't have to deal with that replication. But how would I achieve that > in the most smooth way? Should I go for Compojure for the front end to > not have to deal with two languages? And then maybe skip the > separation of layer "1. Front End" and "2. Business"? > I've not used wicket. Compojure/Hiccup are wonderful, will handle session state no problem, but they aren't a full web framework. You will have to do extra work compared to say Ruby on Rails, Django or Grails where you can get a front-end up in a weekend. > 2. Will it be hard to write a nice web service interface in Clojure? > Is it a suitable communication strategy with Clojure? Maybe I am > making it too complicated? > Web services are easy in Clojure/Compojure (that's worth saying twice). > 3. Clojure has a lot of nice stuff for handling data in transactions. > But if all my data resides in a database will I get to really enjoy > this advantage? I have been thinking about actually storing the data > using Clojure and skip the database, to get more out of Clojure. Is > that idea too crazy? I will have to deal with data replication myself > then, or maybe something like memcache will solve it for me? > Personally, I'd stick with some sort of database as it will have been designed to protect your data from accidents. Clojure has lots of advantages even if you don't use the concurrency features. > > 5. Is it hard to debug Clojure? Using Java/C# today you get a real > treat when it comes to debugging with interactive stepping, expression > watching and a lot of other cool things. Where is Clojure debugging > compared to other languages? Is the debugging features as necessary as > in other languages? > Conventional debugging is harder at the moment but having a REPL or using swank means there is less need for debugging anyway. You can play with each function as you write it. > 7. Any other advice or thoughts you have about this? > I wouldn't worry too much about scaling. Making an application scalable is a lot of work (unless you're using something like Google appengine). Computers are much faster than they used to be. A single machine running Jetty/Compojure with a database such as H2 will handle 100's/1000's of pages per second. If you exceed this your business will be very successful, you will know your application better and then you can concentrate on scaling. Saul -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en