Menu

Tree [505f30] master /
 History

HTTPS access


File Date Author Commit
 src 2015-08-09 pete pete [505f30] Return the object created.
 chatserver.roo 2015-07-06 psouthwell psouthwell [a2cf6a] First checkin Sample chat server using SpringMV...
 pom.xml 2015-07-07 psouthwell psouthwell [511329] Renamed master project to gameland.war /game...
 readme.txt 2015-07-07 psouthwell psouthwell [3edf1e] Less specific package scan.

Read Me

Build:

mvn clean install tomcat:run




Example API:

Important must call the register APIs from external...
curl "http://localhost:8080/gameland/chatserverapi/userregistration/registeruser?userName=pete&externalUserId=12345"

or for existing users:

curl http://localhost:8080/gameland/chatserverapi/userregistration/getUserToken?externalUserId=12345


Returns:


"{   token: \"${serverToken}\"  }"

then I can make server calls..

curl http://localhost:8080/gameland/chatusers?authToken=${serverToken} 
curl -i -X POST -d '{ userName: "222Peter", externalUserId: "aaaa" }' http://localhost:8080/gameland/chatserverapi/chatusers?authToken=${serverToken}
curl http://localhost:8080/gameland/chatusers/chatserverapi/findByUserName?authToken=${serverToken}&userName=222Peter


==============

Here's creating a user in full:

curl "http://localhost:8080/gameland/chatserverapi/userregistration/registeruser?userName=petre&externalUserId=1234111"

returns: { token: "MX4xMjM0NX4tNjljZDE1YjI6MTRlNjUzYjk2MGQ6LTdmZmI=" }

curl "http://localhost:8080/gameland/chatserverapi/chatusers/1?authToken=MX4xMjM0NX4tNjljZDE1YjI6MTRlNjUzYjk2MGQ6LTdmZmI="

return: {"contacts":[],"created":1436217497994,"externalUserId":"12345","id":1,"loggedOn":1436217498002,"updated":1436217498002,"userName":"pete"}

Where as:
curl "http://localhost:8080/gameland/chatserverapi/chatusers/1"

Gives no response.  


Un-Implemented: 


     1) loginUser - Generate a token.... I just put a hokey system in place to show 
        a place holder... 
        
        I envisioned a system where validation was handled external.. And this Chatserver was being aggregated as an internal
        service..  I consider it a subcomponent.
     
     With ChatUser.externalUserId Im assuming this can be used with other user login systems/id... So thus the filter Id think 
     would be a custom option.. Not concerned with the Raw ChatService it'self.  Id tend to use external services to add this.. Such
     As a Security Filter.. Or.. AOP.
     
     2) 
     
     	3a. Caching Service. - I don't like to put things like Caching in the code.. Id user an AOP type methodology and wrap this
        either at the service or DAO level.  You could do this with Extension: or AOP wrappers around the methods needed to be cached.
        The AOP would go to something like Memcache.. or Redis.  This.. You'd put as a layer between the DAO or Service.. Such as..
        
        
        T findById( Long id ) {
        
            String key entityKey = generateEntityKey( id );
            if( ! cache.containsKey(entityKey) ) {
            	return cache.get( entityKey );
            }
            
            T obj = super.findById( id );  /// Non Cached DB READ
            cache.put( entityKey, obj );
            return obj;
        }
        
        Same kind of deal for Saves.. Grab the KEY.. Update it.. Then save it to the DB.. Place it if it's not there.
         
     3) Url level caching.. But.. Probably not for a chat server.
     
     4) Spring has a long pulling feature... For a more event driven type approach...  But in my opinion.. Long polling 
        scales poorly.. But still It's worth considering/exploring:
        
        https://spring.io/blog/2012/05/14/spring-mvc-3-2-preview-adding-long-polling-to-an-existing-web-application
     
     5) A more JavaScript type solution.. WebRTC.. And WebSockets via HTML5.  At this point.. The code would be less concerned with 
        storing the Messages.. And more concerned with creating converstations that had end point data for the clients.. And the chats
        would be peer to peer.  The server would then drive a JavaScript UI for the Client data needed to Drive a Peer to Peer WebRTC 
        chat session.  My reservation about jumping in here.. Would be to make sure that the clients needed to be supported
        accurately and reliabley contained a reasonable and reliable WebRTC stack.  Also.. It may be a business requirement to
        delibarately store the messages on the server.. If that were the case.. then Id go for this design. Store then on the server. 
        Pull them in batches for new messages.
        
        
        
  
    6) How the site would scale..  
    
    			6-1). The controller methods are stateless... 
    			
    			6-2). Optimize queries and add indexes where needed
    			
    			6-3). You add a caching service under load balance... Redis, Memcache, Solr, etc.
    			
    			6-4). You'd deploy multiple chat server .war files.. Also under a network load balancer.  
    			
    			6-5). Perhaps.. MongoDB for a more optimized read/write experience.. As the data isn't vastly
    			complicated.. You'd manage the integrity (Acid) in the code... To provide for fast reads with 
    			indexes at the appropriate level.  This project could reasonably contain different DAOs to facilitate this.
    			I've heard it said.. DAOs are an archaic idea.. But this very thing is the reason for a service layer.. When
    			it's desired to preserve the service logic.. And change only the Store engine.
    			
    			
   8) Intentioned Clients.. Any REST based client.  Probably.. JavaScript.. Or a Native IOS/Android/Windows phone or other rest
      supporting os.
      
      
   9) Use of SpringROO for bootstrapping the empty project.  ROO isn't a framework.  It's a code generator.  It
      generates some pretty ugly code.. But you get to get all the configurations up and running which is a pain
      to do from scratch.  So I tend to start here.  Then I remove ROO from project which is very simple.  Then
      I hand modify the code to be as a I like.. Which involves pretty much redoing most of what they did.. Excpet
      that I find the stubs they create a usefull starting point... IF your starting from scratch.\
      
      http://docs.spring.io/spring-roo/reference/html/removing.html
      
      After that.. I went off... 
      
      	
  It should be noted.. That Id consider chatserver a sub module.  		
    			
    			
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.