ºÝºÝߣ

ºÝºÝߣShare a Scribd company logo

UJUG 2013 Architecture Roundup with Lucid Software

?Download as PPTX, PDF?
?
Derrick Isaacson
Derrick Isaacson

Lucid Software's lessons learned about architecture at the Utah Java User Group. 15 minute presentation by Derrick Isaacson, Director of Engineering, on sharding, session state, typed JavaScript, and ORMs.

1 of 16
Download to read offline
UJUG Architecture Roundup Derrick Isaacson, Director of Engineering
Architectural History
TIE Paid Free Hours in editor by region 10000 8000 6000 4000 2000 0
UJUG 2013 Architecture Roundup with Lucid Software
UJUG 2013 Architecture Roundup with Lucid Software
Client State
HMAC public static String calculateRFC2104HMAC(String data, String key) { SecretKeySpec signingKey = new SecretKeySpec(key.getBytes(), ¡°HmacSHA1¡±); Mac mac = Mac.getInstance(¡°HmacSHA1¡±); mac.init(signingKey); byte[] rawHmac = mac.doFinal(data.getBytes()); return Encoding.EncodeBase64(rawHmac); }
Stateless
UJUG 2013 Architecture Roundup with Lucid Software
Don¡¯t DDOS Yourself ? Use RESTful principles for correct status codes (5xx vs 4xx) so clients know when to rety. ? Use correct headers: ? Retry-After: 120
Actors
Typed (JavaScript) Code Pays Off ? Static type checking ? Unused value detection ? Dead code removal ? Syntax validation ? Style warnings ? JS pitfalls detection
Beware ORMs Anorm is Not an Object Relational Mapper What does a framework really need? ? Paremeterized queries ? Simpler API than JDBC ? Control over your queries
Beware of Coddling Frameworks
UJUG 2013 Architecture Roundup with Lucid Software
Q&A http://www.lucidchart.com/jobs

More Related Content

UJUG 2013 Architecture Roundup with Lucid Software

Editor's Notes

  • #4: 1. Scaling a global web application: LucidchartSurvey captured data from customers in 107 countries with a combined 3.42 years in the Lucidchart document editor.
  • #5: http://pstandsfor.blogspot.com/2012/02/house.html
  • #6: Scala & Play Framework
  • #8: See AWS Docs & RFC 2104Used by the Play Framework, AWS, IPsec, TLS, and many other protocols, services, and frameworks.
  • #10: Shard?everything. ?Dbs are almost impossible to scale horizontally when not sharded. ?You may be going along fine, then one day "bang" you hit a tipping point and your db no longer can handle the load. ?Sharding gives you options.Pick your?shard?keys very carefully. ?Once you have chosen a?shard?key, it is very difficult to change (sharding on documentid in mongo is an example of where we messed that up and it is killing us right now)
  • #11: Single page apps make lots of ajax calls. ?Make sure those calls are done in a way such that if a failure occurs, it doesn't turn around and try again immediately and indefinitely (don't DDOS yourself with your own javascript client).
  • #12: Actors are a great way to introduce concurrency without introducing tons of bugs. ?We added a lot of concurrency to the PDF service and haven't had concurrency related issues (not typically the case when adding concurrency by managing threads).
  • #13: Typed client code pays off (google closure).
  • #14: Beware of ORMs generally. ?They tend to create terrible queries that do lots of joins which should be avoided whenever possible. ?Tools like Anorm allow us to write our own queries. ?SQL is a?domain?specific language: do we really need a?domain?specific language as an abstraction over SQL?
  • #15: Beware of MVC frameworks that do a lot of magic: while they reduce the amount of code to be written, they can introduce security holes (form binds to a model that saves to the db, but a malicious user can add param to the form, post it and modify other fields in the table that you didn't intend the user to be able to modify)
  • #16: Beware of MVC frameworks that do a lot of magic: while they reduce the amount of code to be written, they can introduce security holes (form binds to a model that saves to the db, but a malicious user can add param to the form, post it and modify other fields in the table that you didn't intend the user to be able to modify)